Toward a More Robust Agile


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.


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


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.

Watch that Basket-Seven Ways to Identify Troubled Projects

Leave a comment

Though the traditional advice is “don’t put all of your eggs in one basket,” the celebrated author Mark Twain is famous for saying, “…put all of your eggs in one basket and — WATCH THAT BASKET.”

Whether you’re a an entrepreneur leading a small business , a C-Level executive (CEO/CFO/CIO/CTO) at a mid-sized business, the head of the Project Management Office (PMO), or a business manager watching out for your department, you are often stuck in the position of having to “watch that basket” with your most critical projects.

Even worse, many times you’re never truly sure if one of your key projects is in trouble until it’s too late.

Fortunately, there are some signs that can help you identify a troubled project early, so that you can intervene and put it back on track. I polled our project recovery services specialists at Cedar Point Consulting, and we thought of seven effective ways to identify a troubled project:

  1. Perpetual Green Lights, Little Activity. Many of us are familiar with the approach of labeling projects green when they are on schedule and budget; yellow when the project is falling behind; and red when the project is far behind and/or over-budget. Perhaps your key project has been reporting green for the last three months, but oddly there’s been very little activity related to the project. This is probably a good signal that the project is actually in trouble.
  2. Lot’s of TBD’s. Effective risk and issue management are critical to the success of most projects, yet they are often ignored. If your key project is well past the early stages, but is reporting back a lot of TBD’s (to be determined) in the “resolution” column for risks and issues, then it’s probably a troubled project, even when the schedule doesn’t show it.
  3. Avoiders. The leader in charge of your key project may be a formal project manager or a manager of a business line, but regardless of who they are, you are getting the unsettling feeling that they are avoiding you. Perhaps they are missing at meetings, they’re head the other way down the hall when they see you, they’re not returning phone calls, or they’re not providing status reports. Unless you have a problem bathing, the project leader is likely avoiding you because the project is in trouble.
  4. Troubling Trends. Experienced project managers are familiar in using techniques like earned value management (EVM) to identify project progress by comparing actual to planned results for work completed, costs incurred and time spent. Though you may not be using EVM on your projects, you can watch for dramatic increases or drops in spending, dramatic changes to the work being delivered or sudden changes to schedule with no new schedule dates. In many cases, your key project is in a free-fall.
  5. Non-Progress Reports. You’re wise, so you have asked your project manager to provide status reports on a weekly basis. However, they’re more like “Non-Progress” reports than progress reports because no progress has been made. In particular, if you have received two weekly status reports where no progress has been made, you’re well on your way to having a troubled project on your hands, if you don’t already.
  6. Inability to Show Tangible Results. Well in to your project timeline and knowing that interim reviews are a good idea, you ask for a review or demonstration of work completed thus far. However, your review meeting is repeatedly delayed and rescheduled, sometimes by a few days and sometimes by weeks. Even worse, you’ve tried a quick visit by the desk of the project leader and it resulted in the person shoving documents in their desk instead of sitting with you to review tangible results. If so, this is likely a troubled project.
  7. Spidey Senses Tingling. Like Peter Parker in the Spiderman comic book series, you know which projects are highest risk and every time the subject of your key project comes up, it sets your spidey senses tingling, though you’re not certain why. While I’m a big believer in science over emotion, there is surely something very scientific that you’re reading so trust your instincts. Your likely to find something amazingly like trouble in your key project.

Of course, identifying a troubled project is one thing, but recovering that project is a completely different challenge. I provided some tips to recover troubled projects in a previous article that may be of help.

However, particularly if you don’t have experience recovering troubled projects and the stakes are high, it might be time to consider getting some help.  Our firm provides project recovery services and we’re proud of our success rate, but other competent firms do, as well.

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.

%d bloggers like this: