Home

Toward a More Robust Agile

4 Comments

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.

Agile methodology positioning

Agile methodology positioning

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.

However, it would be great to hear from Agile experts who are implementing Leffingwell’s Agile-at-Scale or making similar changes to Agile to make it more robust.

Without providing confidential information, please tell us…

  1. How large is your organization (people, revenue)?
  2. How long has your organization been pursuing Agile?
  3. How long  have you been working with Agile-at-Scale?  How far are you through Leffingwell’s five step adoption path?
  4. Are you happy with the results you’re seeing?
  5. What are some of the biggest issues you’ve encountered to-date?
  6. Given what you’ve seen, do you think you’re Agile-at-Scale effort will succeed?

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.

Interested in other articles like this one?  Read “Departing Waterfall-Next Stop Agile“.

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.

Advertisements

Before You Make the Leap to Agile – Ten Weaknesses of the Agile Methodology

10 Comments

It’s been nearly a decade since Martin Fowler, Ken Schwaber and fifteen other experts in the software industry wrote the Agile Manifesto outlining an approach to software development radically different from the Waterfall model that dominated the 1980’s and 1990’s. Since that eventful time in 2001, Agile software development methodologies, including the use of Scrum, XP (Extreme Programming) and Crystal, are all the rage throughout business and government, attracting praise like a miracle drug. As of early 2010, Agile is till one of the more popular buzzwords in software development.

If you’re in the captain’s chair as a C-Level IT executive (CIO/CTO), the head of software development, the head of your Project Management Office (PMO) for your business, or the lead project manager in a small organization, you may be considering the leap to Agile seriously. The good news is that Agile is working well for many businesses and on many software development projects.

The bad news is that Agile is not the magic bullet many are claiming it to be. As many successes as there are in Agile development, there are also many failures in both the adoption and use of Agile in software development. (Here’s a list here of some cautionary tales, provided to support my statements, not to complete turn you away from Agile: The Great Pyramid of Agile, Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong, Agile: Anatomy of a Failed Project, A Scrum Project That Failed.)

The fact is that seasoned business and IT leaders, particularly those at larger businesses, should take a closer look before plunging in to the Agile world with reckless abandon. Agile has a number of weaknesses that many disciples of Agile fail to acknowledge. After all, they’re in the business of developing with and helping you to adopt Agile, so they’re not likely to tell you about its problems and limitations.

Together with my friends and fellow associates at Cedar Point Consulting, we’ve come up with this list of Agile weaknesses, which apply to Agile as it is most commonly implemented:

  1. True Agile is rarely practiced. Long-time practitioners will tell you, “It’s Agile – not agile”. Without a doubt, the biggest single problem I have encountered in Agile-practicing shops in the past decade has been that too few people truly understand and practice Agile. In many cases, software developers, development managers and consultants alike mistake Agile for its lowercase sibling, agile, and assume that Agile is all about flexibility and absence of process.This is far from the truth. Agile has formal rules and structure, though they are quite a bit different from those of other development approaches. Agile is iterative, it is adaptive and it is supported by some outstanding tools and techniques, like burn-down charts, product backlogs, user stories and stand-ups. Most important, Agile is not anarchy. It does not mean that everyone does whatever they want and there’s no sense of organization, despite the fact that you may feel this is the case.
  2. Heavy customer interaction is essential. Reflected in principles four and five of the Agile Manifesto, heavy customer interaction is one of the biggest benefits of Agile, but it also becomes a weakness in some environments. Consider, for example, situations where the customers or users of the software being developed do not have the time available to meet with members of the software development team on a frequent basis? What if the key customer is the CEO, who often has more important matters to address? What if you’re not permitted to talk with the users?One important thing to know about Agile development teams is that they are high maintenance – they work quickly, but they also require much more time and attention from the business side to be able to work quickly. If that time cannot or will not be spared for their benefit, using an Agile approach will bring little gain over a Waterfall approach.

Click here to read the rest of this article on Cedar Point Consulting’s web site.

 

Interested in other articles like this one?  Read “Departing Waterfall-Next Stop Agile” and “Toward a More Robust Agile“.

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 process improvement, project management methodologies and technology strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

%d bloggers like this: