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.

The existing work items are probably a hodgepodge of technical tasks, bugs and feature requests hidden away in a todo-system somewhere. Let's start transforming these items into value-focused stories! Every item should end up being phrased as a customer value. Merge small tasks into larger stories and, by all means, use the old "as a x, I want to y, so that I can z" to formulate them. This is very powerful because it forces both programmers and customers to talk and it's the first real step to get them working together as a team.

The next step is to introduce relative estimation. The organization is probably locked into days and hours when estimating, so spend time explaining about relative estimation and velocity. Use examples and let the idea sink in. Programmers loathe time-based estimation, which are always wrong and ends in guilt, overtime and blame. Explain to them that relative estimation relieves the pressure and allows them to be honest with their numbers. Talk with stakeholders, but tell them that relative estimation and velocity makes it possible to plan releases with much more confidence.

With the theory in place and everyone on board, let the cowboys estimate stories, with the customer there to answer questions (be cautious about anchoring). Use your favorite agile planning tool for this. Now would be a good time to introduce technical debt, why it's bad to take on to much of it and how to control it by making continuous down payments. Don't leave the room until all the cowboys have agreed on the estimates!

Excellent, you now have a list of value-based stories that forms the base of something resembling a working backlog. Using estimates as cost and stories as value, we can now start to reason about functionality and make useful prioritization. So next step is to help customers sort the backlog in order of value. Let the cowboys in on the magic as well and encourage their input.

The road ahead should begin to clear by now. The team should start working on implementing the stories, most important first. Keep expectations real and explain that agile is about continuous improvement. Introduce retrospectives at this point, and use it to form values that the cowboys can relate to and start working together as a team, always keeping in mind that the goal is producing value for their customers and business.

[I have left out a lot of details to keep the text short and sweet. Please let me know if you, dear reader, need a guide.]