In a previous article, I put together a list of some of the weaknesses of the Agile software development methodology that I've learned from other software experts and on my own as a consultant serving the technology industry.  As expected, some people were upset that I pointed out so many weaknesses in Agile without pointing out its advantages, believing I was being unfair.   It is true that there are many benefits to adopting Agile over other methodologies.  But, I was actually preparing fertile ground for my next article – Toward a More Robust Agile.

As you may remember, my last article identified ten weaknesses with Agile, including:

1. True Agile is rarely practiced.
2. Agile requires heavy customer interaction.
3. Agile thrives with co-located teams, but struggles with distributed teams.
4. Agile is difficult to scale for large projects and large organizations.
5. Agile provides weak architectural planning.
6. Agile has limited project planning, estimating and tracking.
7. Agile requires more re-work.
8. Agile makes contractual commitments difficult.
9. Agile poses challenges to business continuity and limits knowledge transfer.
10. Agile lacks attention to outside integration.

As I pointed out, these weaknesses should cause some organizations to hesitate before adopting Agile, particularly in large complex environments where most business processes are highly formal and the culture is risk averse.  C-Level IT executives (CIO/CTO), heads of software development, heads of PMO's and lead project managers should research further before considering the leap to Agile seriously.

Fortunately, Agile is not a static, take-it-or-leave-it methodology, so variations, improvements and customizations are being made and adopted as I write this. One of these improvements, however, is worth an in-depth exploration.

Already understanding some of the weaknesses inherent in Agile, one software development expert began to address them in 2007 – Dean Leffingwell. In “Scaling Software Agility: Best Practices for Large Enterprises,” Leffingwell responded to many of the challenges posed by adopting Agile in large-scale environments, particularly items 2, 3, 4, 5, 6 7, 8, 9 and 10 above. In doing so, Leffingwell made Agile both feasible and attractive to large businesses and large-scale software development projects – environments where Agile once struggled.

At the heart of Leffingwell's approach is believing that Agile is inherently strong, but is not without flaws. In his own experience, he saw that some additional structure and planning were needed to coordinate large-scale efforts, much like I described earlier. Leffingwell's response too beefing up Agile is five-fold:

1. Make Architecture Intentional. Rather than treating architecture a byproduct of iterative software development, make architecture planned and deliberate. (Scaling Software Agility, Chapter 16)
2. Use a Lean approach to requirements. First, define high-level requirements early, then hash out details when they're absolutely needed, much like just-in-time inventory. (Scaling Software Agility, Chapter 17)
3. Scale Agile using a team-of-teams, a system-of-systems and release trains. (Systems of Systems and the Agile Release Train: An Agile Whitepaper) . In Leffingwell's scaleable Agile, the key to coordinating large software projects is to break them up into smaller ones and coordinate them, much like a program. According to Leffingwell, just as a group of interrelated projects are programs, a group of Agile teams can be combined to form a program team with program leadership, called a team-of-teams. Each Agile team focuses on a particular piece (component) of the software, or system, which combined makes up a system-of-systems. To pro-actively coordinate the team-of-teams building the system-of-systems, a release train synchronizes the iterations of each team so that their work meshes together at the end of each iteration, ensuring that the needed software features are delivered on schedule.    Beyond a specific release, epics tie many releases together, allowing for long range planning and architecture.
4. Accept the distributed geography of software development teams and provide virtual tools to coordinate global efforts. In Leffingwell's approach, a primary team is placed on-site with the client, while one or more off-site teams share work and coordinate with the on-site team using wiki's, VoIP/Skype and web conferencing. (slide 87, 2007 presentation)
5. Recognize that a shift to Agile is a major cultural change for a large organization, requiring stages and a roadmap. Rather than try to make the leap from Waterfall to Enterprise Agile all at once, Leffingwell suggests a five-step adoption path from individual Agile teams to multi-team programs and on to multi-program organizations. (slide 92, 2007 presentation).

Combined, Leffingwell's Scalable Agile resolves many of the problems that large teams encounter with Agile, at least on paper. For me, I like that Leffingwell borrows from RUP (Rational Unified Process) and Lean manufacturing principles, two topics that I'm both familiar with and respect. I also like that he understands the large organization, the need for heavy coordination throughout, as well as the need for long range strategic, portfolio and architectural planning.

And, as you can see from the diagram below, this re-positions Agile to be more competitive with Waterfall and RUP for larger and more complex projects.



Not accepting theory alone as a solution, however, I talked with a friend who is implementing Leffingwell's version of Agile-at-Scale in his organization to see how the effort is going, where the organization is encountering issues and whether he thinks Agile-at-Scale will work for them.  Though I can not reveal confidential information, he was able to provide anecdotal support for Agile-at-Scale, which is quite promising. 

While it's a little early to tell, Agile is clearly evolving to become more attractive to larger, more structured organizations and maturing to provide a viable alternative to Waterfall and even RUP.  When I return to this topic, I will talk about some ways to ease in to Agile, adopting Agile tools and techniques in your environment without completely abandoning a Waterfall approach.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.