I’ve been asked by quite a number of people, in a variety of forums, what the real end goal of agile is. The context is normally prior to embarking on a transition to developing software along agile lines, and when trying to get a handle on the organisational cost/benefit trade-off.
My stock answer is that it is about quality and building the right product. It’s definitely not about productivity. It’s also about visibility into product development and putting trade-offs around prioritisation of features and fixes in the right hands in the business. It’s definitely not about productivity.
I have a longer answer where I describe some of the details of XP and what the real benefits are that we have accrued since switching. I can also speak at length about the organisational cost, in terms of lost resources, transition time and the inevitable path along the satir change curve for the people involved.
The question of productivity always comes up, especially in the context of pair programming (surely it’s half as productive to have two people do a job as it is for one person to do it?). Setting aside the full answer to that, which is about getting the work right, avoiding knowledge silos etc. I did secretly wonder whether I could find any measurable evidence to back up my intuitive feel that by adopting agile fully we *would* see productivity gains.
So in spite of it not being a primary rationale for the switch, my belief – and experience – was that improved productivity is a beneficial secondary corollary to agile. I had a perfect chance in an upcoming project where I was implementing XP over the top of an existing team and asking them to go through the transition. As we went we would have our velocity to use as a measure of our productivity, so we started to track it.
Here’s what happened…
First thing to note is our headcount dropped. And quite dramatically. We lost people who didn’t like the new way of working, the new working environment, and their new role in their team. I expected some of this, but it was surprised at how many. There were other problems in the team which I think were just as much to blame, and eventually someone’s decision about their employment is a complex and personal issue, but nonetheless, we definitely descended into a little chaos as people left when agile arrived. The more surprising result was that, in spite of the seeming turmoil, the depletion of resources, the learning of new working practices etc. we saw the team velocity steadily increase.
It’s fair to say that velocity is a function of your ability to plan, and when you start planning in agile you learn about the meaning and value of a story point and it takes a little while to settle into a repeatable pattern. However, the errors in planning estimates that give rise to velocity tend to be normally distributed, so it settles, and quicker than you might expect.
The end point of this transition is that there are fewer people on the team but there’s more work going on. Obviously during transition we saw it flip around a little, but it has definitely settled into a place where the team is doing more with fewer resources. If I ignore velocity for a moment and just look at the real measure of activity, which is working product, then by that measure we are doing much better than we were with the previous team and practices.
So I’m going to change my stock answer to include the fact that, done right, agile can quite quickly result in productivity gains.