- Overview
- Thinking Lean
- Applying the Agile Manifesto at Scale
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Applying the Agile Manifesto at Scale
The brief document that launched this massive movement is more than 17 years old. Since then, not one word has changed. So, it’s fair to ask, given all the advancements in the last 17 years: Is the Agile Manifesto still relevant? Or should it be treated like a historical document that has long since served its purpose?
What’s more, Agile was defined for small, potentially fast-moving software-only teams. And that raises another valid question: Does the Agile Manifesto scale? Does it meet the needs of enterprises developing the biggest and most complex software and systems? Does it serve the needs of systems that require hundreds of people to build them and have unacceptably high costs of failure?
Rather than judge Agile’s ability to remain relevant on our own, what better way to assess the manifesto’s practicality than by asking the people actively engaged in building these new systems? Specifically, we routinely ask SAFe students to do the exercise described in Figure 3-3 in class.
)
Figure 3-3. Agile Manifesto class exercise
The typical response is that principles 1, 3, 4, 7, 8, 9, 10, and 12 ‘work as-is.’ The conclusion is that most Agile principles scale without requiring any rethinking, and indeed, most need even more emphasis when applied at scale. The other principles typically foster a little more discussion, as highlighted here:
Principle #2—Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. The comments here are, ‘It just depends.’ This reaction doesn’t reflect indecision on the part of the class participants. Instead, it recognizes that the cost of change for some types of late modifications may create situations that are not feasible. (For example, can we change the optical resolution of a geophysical satellite a few months before launch?) And yet, if it’s a software-only change, and the program can still meet any compliance and validation criteria and launch on time—then, yes, we welcome that change.
Principle #5—Business people and developers must work together daily throughout the project. Most are certainly willing to comply with the spirit of this concept. However, there are limitations on the economic practicality and convenience of daily onsite feedback from customers of large programs, though we fully agree with the sentiment. SAFe actively responds to this principle through roles such as the Business Owner, Product Owner, Product Manager and Solution Manager, and System Architect/Engineer. SAFe teams engage the customer directly at system and solution demos and at many other points throughout the development process.
Principle #6—The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Everyone agrees with the intent of this principle. SAFe addresses this point, in part, with Agile team iteration planning and periodic face-to-face PI planning events. Such events meet many of the needs for efficient communication at scale. However, if you are dependent on a supplier to build a smart power supply to fit the physical and thermal constraints of your satellite, you would indeed want to speak to that supplier continuously, but you would also document the results of those decisions as an ongoing form of communication. Fortunately, “working software over comprehensive documentation” does not mean instead of. Most serious Agilists proceed knowing the intent, as well as the practical limitations, of that principle.
Principle #11—The best architectures, requirements, and designs emerge from self-organizing teams. Nearly everyone agrees with this principle—depending on how you define a team and the subject and scope of the decisions! Everyone agrees that when you consider an ART as ‘the team,’ the addition of some architectural and other governance—combined with the ability of all the Agile teams on the ART—can absolutely create the best “requirements and design” for the elements in their domain.
The conclusion from this exercise is that the Agile Manifesto does indeed scale. However, many principles require increased emphasis at scale, while others require a more expanded perspective. The Agile Manifesto remains as relevant today as ever, perhaps even more so. We’re fortunate to have it, and it plays a vital role in SAFe.