Topic: General
I hear so many different opinions about what is or isn't feasible for agile teams, which agile practices are or aren't practical, and which projects are or aren't "agile" that I sometimes wonder how we can ever communicate our ideas about agile development in an unambiguous way. Recently it occurred to me that the adoption of agile thinking in the industry is a bit like a marathon. At the start of the race, everyone is lined up in the same spot. Ninety minutes into it, the runners are spread out over the course. Some are farther along than others. Some are very, very far behind and there is virtually no chance they will ever complete the course, even at a walk, yet they feel as if they are just as much a part of the race as anyone else and they wouldn't appreciate being labeled as "not runners at all."
Agile adoption is like that, too. If we take the official start of the race as February, 2001 (when the Snowbird meeting took place and the buzzword "agile" was coined), we might say everyone in IT was lined up in the same spot. Seven years after the starting gun, we're spread out all along the course. Some have moved far along, some are still pretty close to the starting line, and most are somewhere between. The leaders are already critiquing the quality of the course and thinking about how to organize next year's race. Back toward the starting line, a few seem to be jogging around in a circle, having merely re-labeled their old work habits as "agile," yet they feel as if they are just as much a part of the race as anyone else and they wouldn't appreciate being labeled as "not runners at all."
As of mid-2008, different organizations and different teams are at different levels of maturity in the application of agile principles. Most of the IT industry hasn't embraced agile at all just yet. Of those who have embraced it, most are trying to master the art at the maturity level labeled A in the illustration. Some are ahead of that point, and are collapsing role-based siloes to reduce work-in-process inventories and hand-offs, shortening feedback loops, pulling tests forward, and removing still more overhead from their process such as task-level estimates in ideal time and iteration burn-downs. Thought leaders in the community are exploring ways to blend in good ideas from other sources, such as CMMI to achieve better scalability, predictability, and repeatability, while reducing waste even further through Lean principles. Looking ahead, some are considering how organizations need to restructure and how managers need to adjust their thinking in order to take better advantage of the potential benefits of agile and lean methods.
The wide range of opinions regarding feasibility and practicality of particular agile techniques may simply be a reflection of different individuals' experiences to date. Those who believe certain practices aren't feasible may have experienced difficulties when they attempted to introduce agile methods in organizations that weren't prepared for change; once burned, twice careful. Those who have had good results at maturity levels A and B are in a position to see, and therefore to try and knock down, the next level of impediments in the pursuit of excellence.
Circa 2002 the leading edge corresponded to maturity level A, the ideas listed under B would have been considered pie in the sky, and the concepts at maturity levels C and D weren't on the horizon at all. True to agile principles, empirical information from agile projects has informed continuous improvement in agile methods and enables us to push the envelope day by day and year by year. It's an exciting time to be involved in the IT industry!
