Friday, September 19, 2014

No Estimates Minus Continuous Delivery Equals ???

I'm still thinking about No Estimates. So far, I've talked about how the business already behaves with a No Estimates mindset, about how developers need to be an integral part of the business, and about how organically grown software adds value to the business (and more here).

There are a lot of things that attract me to this mindset. And I also have quite a few reservations. I understand that tools have their pros and cons and that no tool is the right answer for every situation. The same is true of No Estimates. It definitely has a set of problems that it targets, but there are some other problems that aren't addressed. I don't expect that No Estimates has an answer to these problems, but I'm wondering if there are elements that we can incorporate into these other environments.

Continuous Delivery (or not)
Continuous Delivery is an amazing thing. If we can release updates to our software with a regular cadence at (hopefully) brief intervals, we can keep adding value to the business without having to wait for quarterly releases or "big bang" updates.

The examples of the organically grown software fit in nicely with the idea of continuous delivery. Although there wasn't a regular cadence, we did keep adding functionality in small pieces which gave the company value on an ongoing basis.

And for many of the other projects that I've worked on, many of them could have been split up into small chunks that were delivered on a regular basis (after hitting that "minimum viable product" stage). But there are some other projects that are more difficult to break down to fit into a continuous delivery process.

Quarterly Releases
As an example, I worked for a company that produced authorization software. Anything security related is already under high scrutiny. And on top of that, this was software that is installed at the client's site (and often isolated from external networks).

In this environment, there is no way that we could do weekly or monthly releases. When we had a new release, our clients would set up development and QA environments to test the new product. This included both functionality tests and penetration tests. Only after the software had gone through this process would they install it in the production environment. This process could take several weeks. So even if we were doing weekly releases, none of our clients would upgrade on that schedule.

So, you might suggest that we do the weekly releases, and then the clients can pick which features are important to them and upgrade when they find something compelling. And that initially sounds like a good idea. But our support system made this nonviable. When a client called with an issue, we would need to replicate their environment in the lab and then possibly provide a patch if the software had a problem.

This meant that we needed to keep working branches of prior releases available so that we could patch that particular release (without forcing the client to upgrade to the latest version).

"Big Bang" Release
As another example, at a large company, there was a project to replace an aging scheduling system. Scheduling tens of thousands of employees on a regular basis is difficult enough, but when you add the various rule sets that come from state regulation, company policy, and union contracts, things get complicated. (Fortunately, I was not on this particular project, but I did get to interact with a lot of people who were.)

This is where it becomes difficult to come up with the "minimum viable product" for the initial release. If you target one group of employees, you find out that their particular union covers more than just that group, so you need to expand the scope of employees included. If you manage to find an isolated group, you find that some of the employees move back and forth between departments (depending on how busy things are).

When you take the variables into account, the "minimum viable product" comes so close to "full replacement" that it doesn't make sense to do things incrementally.

And I'll be the first to say that this is a difficult way of doing things. There's no way to get everything right the first time (especially with this type of release), which means that the first six months after release are going to be a bit painful for the users and the development team.

Moving Into The Ridiculous
This can stray into the territory of "What the heck are you thinking?!?" I came across a group of business analysts who were collecting requirements for one of these large, company-wide projects. They were on a 24-month requirement gathering mission. Let me repeat that: 24-month requirement gathering mission.

That's 2 years! Even in a slow-moving corporation, things are going to change faster than that. By the time you get to the end of 2 years of requirements gathering, you'll just find that the business has changed, many of the features are no longer needed. And there will be a gap for features that are truly needed but came up too late to be included.

No Estimates - Continuous Delivery = ???
Now some of these examples are extreme, but it does bring up the question: can we get benefit from the principles behind No Estimates even if we are not in an environment where we can implement Continuous Delivery?

For example, in the quarterly release scenario, each of our clients had features that were important to them. It's not really possible to give each of them a "yes that's in this release" or "that will be in the next release" unless we are doing estimates on how long the various features will take, how much bandwidth we have from our development team, and what our planned release looks like. Definitely not a "No Estimates" mindset.

I don't have the answer to this. It may be that we need to come up with better ways of determining what the "minimum viable product" is. This is not too hard when working with green-field development. But when working on system-replacement projects, it's a bit harder to convince the business area that they need to stop using one function in the old system so that they can use it in the new system (especially when there is no practical way of actually disabling the feature in the old system).

It may be that we need to have better delivery mechanisms. If you are deploying just to your own servers, then it becomes much more practical to do weekly or daily releases. And there are some web-based companies that do multiple releases throughout each day.

This is a viable solution for server-based software that we run on our own servers or put into the cloud. It is more difficult if the software needs to be installed on servers at a client location. (And I would bet the majority of clients don't really like the idea of "auto-update" on their servers -- but that thinking will gradually change as people integrate more cloud solutions and see more and more successful updates.)

Wrap Up
As you can see, I've been thinking quite a bit about this. I really like the idea of No Estimates, development by subscription, and continuously adding value to the business. I think that I've identified a number of scenarios where this works well, and it really just requires buy-in from everyone involved.

But there are some scenarios where it doesn't seem to fit at all. I don't want to abandon the ideas (because they are good ones), and I'd like to see if there are small elements that we can bring in to these projects to improve the development process.

No tool is perfect for every job. But there's got to be some good principles that we can bring over into these other environments.

For more info, feel free to join the #NoEstimates discussion on Twitter, or look up Neil Killick or Woody Zuill. And I'll be glad to hear any of your insights on this topic.

Happy Coding!

No comments:

Post a Comment