The Agile Checklist

Because you have to count them, that's why.

Let's say you have 100 software teams and you are trying to help everybody start a more agile approach. How do you measure how things are going? How about if you have 1,000 software teams?

At some point, big organizations have to count things. It's just the nature of being big companies to have to count things that small teams do not have to count. It's also reality that many things that large organizations count are imprecise at best, but that doesn't mean there is no value in counting them. For instance, average man-hours per project is useless for a lot of reasons, but it can give a very rough idea of how fast the company will be burning money in the future.

So it's a given you have to count things in large organizations, even if counting them is problematic. The obvious next question is: so how the heck do you actually tell if a team is agile or not, anyway?

Oddly enough, I run across a lot of teams in large organizations that look agile but aren't. In other words, they go through all of the motions but the spirit of agile is completely missing. Giving these folks a checklist will be like pouring fuel on a fire: you can bet the checklist will be followed, even if the team is miserable and all of the deadlines are missed.

So how about a list that indicates whether a team appears to be doing the minimum amount to implement agile? A list that would show "We believe you are trying" Such a list would look something like this:

• Adapt - Always ask yourself what is wrong and what you need to do to fix it. If you continuously communicate to identify problems and fix them, I believe that in a normal world you will do the following things that I can observe:
• Time-Box - You have a fixed, immutable time-box in which you deliver tested changes (either code, documents, processes, beans, whatever) that be demonstrated
• Togetherness - The closer everybody is, the better. Co-located, non-cubicle, non-office spaces are best. Highly matrixed, separated teams are worst.
• Value - You have a clear way of determining the most valueable thing to do each iteration. Business Owners give you business value. Technical Owners give you architectural value.
• Ownership - The team, and only the team, owns its estimates. Outside factors are considered and can be communicated, but at the end of the day the team has the power to determine the amount and type of work it can take on for each iteration.
• Forecast - Being agile and empirical does not preclude precictability or forecasting. In fact, the value of agile teams is their ability to take highly-changing environments and put some kind of predictable forecastable order in them.

So if you're in need of a checklist to count up how teams are doing, here's one for your consideration. Each of these has measurable attributes -- someboby can go around and check to see if they are there or not.