In my continued work with some of the larger software enterprises, sometimes I am still surprised at just how difficult mastery of agile practices can be. (Of course this affects only those concerns with the courage to try!) And it’s hard twice:
Once – at the team level, as the individual component teams struggle to master the basic agile practices. In order to be successful, all cooperating teams must adopt and adapt the basic agile project management practices (mastering iterations, component teams, daily stand-ups, individual and team accountability, complete visibility and the like) as well as the software engineering practices (shared code ownership, cross training, concurrent testing, incrementalism, continuous integration and the like). Each of these taken alone can be difficult in itself, but when taken together the challenges mount up. Further these changing practices drive additional changes in team and organizational behavior, team and individual responsibility, personnel and role changes. In my experience it takes many months (4-6-8 or more) for a team to get “in the flow” where they can reliably deliver potentially releasable software in small increments, and it’s not unusual to see teams take up to one year to really be on their game.
Twice – at the enterprise level, when the impact of improved team productivity starts to affect the rest of the organization. That’s when the company comes to realize that there are additional changes that need to be addressed. These include extended enterprise practices (requirements and architectural governance, multilevel release planning, impact on customers and operations, enterprise-scale rollout and the like). Moreover, many of the method and procedural practices we have used in the past to address these larger concerns have been abandoned by the agile teams. There is not likely to be an all encompassing pert chart, critical path analysis, marketing requirements document, project manager, software requirements specification, written test plans, documented architectural models, etc. in existence to guide the company through the challenges. And if they do exist or the teams are forced to create them, they’ll likely and rightly be rejected by the teams as the wrong way to address the remaining problem set anyway.
Fortunately, all is not lost and there is wide and growing body of experience that helps the enterprise move forward.
At the team level, there are dozens of great books on agile development and they are generally lightweight and accessible. In addition, the growth of the Scrum Alliance and its certification process has put hundreds (maybe thousands by now) of agile coaches into the field to help the nascent teams. And as the movement has grown, in all probability there is some number of individuals in the company with substantive agile experience and those people can be the flag bearers and coaches for the new teams. So bottom up, team by team, there is a lot of guidance for the team. That doesn’t make it easy but it does make it practical.
At the enterprise level however, there is much less documented (see reference list of Leffingwell – Scaling Software Agility: Best Practices for Large Enterprises, Eckstein- Agile Software Development in the Large and Schwaber- The Enterprise and Scrum) on how to scale agile to the enterprise level. (Indeed, one sees some agilists who would debate whether that is even the right thing to do.) In addition, there are far less teams/companies etc. who already “get it” from their prior experiences. So it is newer territory. Of course, that’s why I wrote the book
As for the latter, while there can be no substitute for experience and the full set of best practices in Part III of the book, I’ve also come to the conclusion that effective Release Planning (synchronized, multi-level release planning that is) is one of the critical and relatively straightforward keys to understanding agility at enterprise scale. While I covered it somewhat in Chapter 12 – Smaller, More Frequent Releases and in Chapter 18, Systems of Systems and the Agile Release Train, I didn’t emphasize it as a significant and somewhat stand-alone enterprise practice that I now see it to be. To address this shortcoming, I’m writing an article on release planning from the inside out, i.e. an experiential, day-in-the-life emulation of a team lead experiencing an enterprise release planning session. This article should be published in
March 12 edition of the Agile Journal, Sharing Agile Successes. In addition, I intend to describe it more succinctly in some upcoming posts this week.