November 1, 2010

Agility Means Deploying Software More Quickly

At the Software Test Professionals conference this week, Kent Beck, the creator of Extreme Programming, gave one of the most eye-opening keynote talks I have heard. It was on agile development, except that it never used the word agile.  Instead, he focused on what it would take for an organization to deploy software more quickly. Specifically, he looked at what would have to change in the processes to move from deploying software annually to quarterly, quarterly to monthly, monthly to weekly, weekly to daily, and daily to hourly. He was speaking to the wrong audience. Actually, it was the right audience, in that a good part of the processes he described as having to change were quality and testing ones, but the audience wasn’t particularly receptive to his message. I suspect it was because he advocated breaking down barriers that most don’t want to see broken down. Beck noted that one of the primary barriers to increasing the frequency of deployments is the distance that communication has to travel in an organization. The focus of agility is to reduce the distance communication has to travel. I’ll give an extreme example: I worked as a product manager for a software development organization. We had the usual functions – sales, marketing, tech support, QA, and engineering – co-located in the same building. However, each of these functions reported up their individual chains of command to a remote headquarters. At one point we were instructed by senior management that any comment, request, or need had to go up our functional chain of command to the VP level, where it would be communicated between the VPs involved and sent back down the target chain of command to reach the person sitting in the next cubicle. The reply had to follow the same path back. Agile we were not (and in practice we pretty much ignored this directive when we could). But Beck claimed that a principal barrier to increasing deployment frequency is the organizational distance a message has to travel. As a team moves to monthly deployment, for example, it may not make sense to have a separate QA organization. Instead, perhaps you pair up developers and testers, much like the concept of paired programming, so that the lines of communication are between individuals engaged in the same task, rather than two separate organizations engaged in different tasks (though in support of the same goal). On a related note, Beck claimed that when you deployed more frequently, technical disputes didn’t have to be resolved by strength of personality or by dint of organizational stature. Instead, you deployed one approach (or possibly both), and if it didn’t work, you simply changed it the following week or month. I think Beck is on to something here. Agile is something that developers and development teams understand.  Deployment frequency starts to cross over into the realm of business needs. Beck noted that the CTO of assessed the health of its applications by looking at a business metric—dollars per minute in sales. If there was a technical problem, it would likely show up on the business side first.