Now that Agile has crossed the Moore's technology adoption chasm, I'm seeing more and more organizations asking serious questions about Agile software development. According to the Dr. Dobb's 2007 Agile Adoption Survey (www.ddj.com/architect/200001986), 69 percent of organizations in North America have run Agile pilot projects and 85 percent of them have run several. Now that organizations have gotten their feet wet, they're starting to think about how to scale Agile approaches to meet their real world needs. A critical question that many people are asking is, "How do you govern Agile projects successfully?" The answer, which often surprises people, is that it's a heck of a lot easier to govern Agile projects than traditional ones.
Many traditionalists will claim that Agile projects are difficult to govern, but nothing could be further from the truth. To be fair, most of these people are likely confusing code-and-fix projects with Agile projects, and without a doubt, code-and-fix projects are virtually impossible to govern. There are two aspects of Agile software development that promote superior levels of governance when compared to traditional software development. First, the Agile approach of producing working software on a regular basis provides stakeholders with greater visibility into what a project team is actually doing. Second, the greater level of involvement provided to stakeholdersthey control the budget, scope, and schedule on Agile projectsenables them to direct the project teams effectively.