Dealing With Cowboys, Part II

The previous post on how to approach cowboy businesses concluded with:

Stakeholders should handle the business, not the developers. That should be the focus when dealing with cowboys: wresting control back to the customer and help them slow down their frantic code herding. Pull in the reins if you will.

A quick recap: Cowboys have seized control over the process. This means a lot of time is spent doing stuff they think is most important and not necessarily what is most valuable for their customers. And here lies the key to success: get the organization back to being in a constant focus on providing customer value.

The first step is talking to them about value-driven development, minimum marketable features and the importance of that throughout the entire development process. Explain why "business value" is the language they should be using when defining work items and not technical features. This is the easiest and most hands-on way to begin the transformation. It's also the only way customers and stakeholders can understand what the programmers are actually working on.

Does Late Have any Meaning?

Anytime you make a commitment of some kind, you run the risk of being late. That applies to agile as well.

But we know you cannot predict the future, and we know the customer will constantly change his mind, and we agree that is a good thing. If we accept that, we must also accept that all commitments are pretty much always wrong, which, in turn, makes the question about lateness easy to answer:

We are always wrong. It's all a matter of guesses, no matter how well polished. This is something we simply must accept, and from that standpoint find another way to work, a way in which the lateness issue is made much less important. A change of perspective.

The way to do that is making continuous deliveries of working software, with an option of stopping the project when the client is satisfied. And that is what agile is all about. A clever way of managing this uncomfortable notion that lateness is a fact and we simply have to deal with it the best we can.

For example, you are late when you fail to deliver on the commitments you did at the beginning of the current iteration. This is expected and you should learn from this and adapt your process so you are less likely to fail in the next iteration. The best way to handle this is to keep iterations as small as possible.

For multi-iteration planning, aka release planning, you use the velocity calculated from the completed iterations and extrapolate the data to a predict a future release date. I recommend James Shores' article or my own (shorter) for more details about this. Note that it's never a solid commitment though and more of a "we are 80% certain that we will complete the next features by that date". This can (sort of) result in you being late, but the commitment is only a probability, not a fact.

Now par this with the basic promise of agile that you should always by able to release working software, feature complete or not. This gives the customer the freedom to stop development when he thinks the system is good enough, which can happen a lot sooner than anticipated. It also encourages taking the project in new directions based on real feedback from the latest iteration.

The above points should be more then enough for any customer to be in full control of the development, and I hope that answers the question about lateness in agile methods.