Every year, people talk about the future of IT, which is shorthand for, "Some big changes may be in the works." In the last year, we've had to revise that sentence to read, "Some big changes are definitely in the works."
Agile practices will be a critical tool for making this transition successfully, but not because of velocity. At least, that won't be the primary virtue of Agile that helps with the transition.
One of the Founding Fathers of Agile, Jim Highsmith, recently commented on his blog about an MIT study that surveyed one face of this mountain of change:
Not surprisingly, Forrester's analysts strongly agree. James Staten and Alex Cullen surveyed the same mountain of change, from a slightly different angle, and came to similar conclusions. Three major forces - increased business complexity, self-reliant employees, and self-service technology - are pushing IT up this hill. During earlier periods of change, IT led the journey to the summit. This time, "empowered" business users are the technology Sherpas.
But why would someone like Highsmith, who helped originate a software development methodology, necessarily be interested in IT's new trajectory? One might take a reductionist viewpoint of a software development methodology like Agile, treating it as if it were a guide to how development teams operate. In this simplistic view of Agile, the chief benefit of Agile, velocity, is irrelevant to direction. "Move faster" doesn't tell you in which direction you should move.
If I haven't made it obvious enough in the preceding paragraph, that reductionist view - what you might term "vulgar Agile" - is completely off-base. While velocity was one of the intended benefits of Agile, it wasn't the only one. The principle of the Agile Manifesto also point in the direction of other intended outcomes, such as better quality software, less time spent on activities that don't add value, and (the critical benefit for this discussion) greater openness to change.
In our own research on Agile, we've seen Agile practitioners take that principle to heart. For example, when we surveyed people about the reasons why they adopted Agile, four reasons effectively tied for first place: greater frequency of releases, better business/IT alignment, more opportunities for midcourse corrections, and improved product quality. Other changes, such as greater predictability of releases and increased team morale, follow closely behind. Velocity is important, but clearly it isn't everything.
In fact, looking at this list of potential benefits, velocity isn't necessarily the critical improvement that makes all other improvements possible. You can develop software more quickly and still have unhappy business users, lots of bugs, schedule slips, and disgruntled team members. If I were to nominate the essential benefit of Agile, my choice would be adaptability, to both external and internal circumstances. For example, every design needs a second draft, so teams have to be ready and willing to respond to even the harshest feedback from business users. Similarly, it's pointless to invoke the Agile principle of self-organising teams if the team is afraid of making these adjustments or if upper management doesn't trust the team to make them.
The transition we're discussing is big, changing both IT in supporting business users as well as IT's image of itself. Therefore, the transition requires changing both practices and culture. That's exactly what Agile is good at doing. You can't become Agile if you pay lip service to the ideals but fail to adopt the disciplines. Embracing the formalities without the "spirit of the law" is just as prone to failure and disappointment.
Therefore, if you're working in an IT organisation and you haven't yet adopted Agile, here's another reason why you should start experimenting with it. As Sir Edmund Hillary famously said, "It is not the mountain we conquer, but ourselves."
Posted by Tom Grant