Project Management Institute

The End of Agile? No, the End of Undisciplined Agile.

sticky notes on glass wall in office building

Photo by İrfan Simsar on Unsplash

Scott Ambler

Scott Ambler

Vice President and Chief Scientist Disciplined Agile, PMI

29 May 2020

Scott Ambler counters a Forbes article entitled “The End of Agile” to argue that agile is very much alive, offering insights into how teams can adapt their approach to leverage agile strategies in a way that will allow them to succeed in their unique context.

Late last year, Kurt Cagle penned an article for Forbes entitled “The End of Agile.” Forbes regular Steve Denning delivered a thoughtful response a few days later with “Why Agile’s Future is Bright,” but I’d like to expand on the topic with nine powerful ways to maximize agile. 

  1. Look beyond Scrum. Cagle started out his piece with a tongue-in-cheek description of an agile team: “I knew the end of agile was coming when we started using hockey sticks. Every morning, at precisely eight o'clock, the team of developers and architects would stand around a room paneled in white boards and would begin passing around a toy hockey stick. When you received the hockey stick, you were supposed to launch into the litany: Forgive me, Father, for I have sinned. I only wrote two modules yesterday, for it was a day of meetings and fasting, and I had a dependency upon Joe, who's out sick this week with pneumonia.” However, he is really describing a small team at the very beginnings of learning Scrum. This is the classic “Scrum = agile” mistake that many people make, and it plays well to people who only have a passing understanding of how agile works in practice. We recommend that you look at teams that are succeeding with agile, rather than teams that are clearly struggling. Better yet, let’s help the teams who are struggling—rather than making fun of them. 

  2. Beware of agile purists. Cagle’s observation that agile has become a religion wasn’t far off. It might be more accurate to say that there are agile purists out there, and these purists often prove to only have experience with applying agile in straightforward situations, rather than in the enterprise situations that he describes. But there are also agile pragmatists out there who are actively addressing how to apply agile and lean strategies in less-than-ideal situations. (Let’s remember that “Be pragmatic” is one of the Disciplined Agile™ principles.) Disciplined Agile encourages practitioners to remain open-minded and pragmatic, aim to do the best they can in the situation that they face, and always strive to learn and improve. 

  3. Agile works in a very wide range of situations. There is ample research data and case studies showing that agile works in a wide range of situations. For example, in our 2016 Agility at Scale survey we found that organizations were applying agile on large teams, in complex domains, even when using legacy technologies (including legacy data sources). Agile was being used in regulatory environments, as well as in multi-organization situations including outsourcing. That’s just the beginningwe have data from other studies going back over a decade that show that agile strategies have been applied beyond the “small teams with straightforward problems” scenario for quite a while. We recommend that you look around and see how agile is being applied in practice.

  4. Scaling agile requires discipline. Cagle also argues that agile doesn’t scale well to address big problems, yet many organizations are doing just that. To be fair, this is a common misunderstanding that is a result of a common mindset that equates Scrum with agile; this leads to misconceptions because Scrum purposefully doesn’t address areas like architecture among other areas. But other agile methods do—in particular Agile Modeling and Jim Coplien’s excellent work around Lean Architecture: strategies which are explicitly reflected in the range of options available through Disciplined Agile. In Disciplined Agile Delivery (DAD), teams explicitly include initial architecture modeling early in projects via the Identify Architecture Strategy process goal. DAD teams also have someone explicitly serving in an Architecture Owner role who is responsible for guiding the team through architecture decisions. Furthermore, there is a specific Enterprise Architecture process blade to support organization-level architecture issues. Finally, DA promotes the idea that Architecture Owners and Enterprise Architects should work closely together. Our recommendation is to explicitly address architecture in your way of working, for which Disciplined Agile provides clear options.

  5. Data projects can be difficult. The same can be said of non-data projects too. When either domain complexity or technical complexity arise, you need to become more disciplined in your approach to requirements and architecture modeling. As Cagle implies, data projects often suffer from domain complexity, particularly in for the enterprise data systems he mentions. Similarly, data projects tend to suffer from technical complexity; after all, they need to integrate data from many disparate sources that often use different technologies, apply different semantics, and are accessed via different strategies. Once again, the context-sensitive choice-driven strategy promoted by Disciplined Agile wins the day over the prescriptive methods and frameworks Cagle describes. To confuse matters further, frameworks such as Scrum and SAFe have virtually nothing to say about addressing data issues. Disciplined Agile, on the other hand, encompasses proven strategies from the Agile Data method which are critical to success on data projects. Our recommendation is to embrace the complexity that you face—and recognize that you will need to explicitly tailor your way of working (WoW) to address that complexity. 

  6. Agile is applicable to data projects…and may be the superior approach. I’m going to be blunt hereKurt Cagle was completely wrong concerning the application of agile strategies to data projects. While traditional data professionals often prefer to do extensive data modeling up front, this strategy has been shown to be ineffective in practice. What does work well is an agile data modeling strategy in which high-level modeling is performed early in a project and detailed data modeling is performed as needed during construction. You can be very agile when supported by database practices such as database refactoring and automated database regression testing. His claim that the focus on enterprise data is relatively new clearly doesn’t reflect the wealth of techniques around enterprise data modeling and meta data management that the data community has been following since at least the mid-1990s. And yes, there are agile approaches to all of those practices. As an aside, I started writing this blog in the evenings while attending the World Wide Data Vault Conference in Hannover. Most of the presenters have discussed how they’re taking, or at least supporting agile—and often a Disciplined Agile—approaches on their data projects. 

  7. Many large and complex open source projects benefit from agile and lean strategies. Contrary to what Kurt claims, Linux (operating system), Hadoop (big data processing), MongoDB (database), Numenta (machine learning), Angular (web application framework), and Docker (software infrastructure) are just a few such examples. But hey, it’s not as if any of those technologies have become mission critical for your organization. (Yes, I’m being sarcastic.) And his discussion of games development? Having actually consulted to several commercial game companies, I can safely say that they were all working in a very agile manner. 

  8. You must adapt your approach to address the context that you face. One process size does not fit all. Two of DA’s principles are “Context Counts” and “Choice is Good”different teams in different situations will choose to work in different manners. If you want your teams to be effective then you have to allow them—and better yet, enable them—to choose their own way of working (WoW). 

  9. Adapting your approach requires skill and experience. In some ways, Cagle is rightenterprise-class problems require an enterprise-class agile approach. But he was wrong in assuming that because people were struggling to apply undisciplined agile strategies to these situations that agile didn’t work; the real problem was that they didn’t know how to make it work. The fact is that others have figured these things out, and we’ve captured a lot of these strategies in PMI’s Disciplined Agile (DA) tool kit

As Steve Denning points out, this certainly isn’t the end of agile. But let’s hope this is the end of undisciplined agile—and let’s look towards a future where Disciplined Agile provides the right solution for each unique situation.