- Overview
- Thinking Lean
- Embracing Agility
- 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 industry movement is more than 15 years old. Since then, not a word has been changed. It’s legitimate to ask, given all the advancements in the last 15 years, whether or not the manifesto is still relevant. Or should it be treated like a historical document that has served its purpose?
Moreover, it was defined for small, potentially fast-moving software-only teams, raising another legitimate question: Does the manifesto scale to the needs of enterprises developing the biggest and most complex software and systems? Does it serve those that require hundreds of people to build and have unacceptably high costs of failure? Although the manifesto might not have been designed for them, can it be applied?
Rather than judge these questions on our own, what better way to assess its practicality than by asking those who are actively engaged in building these new systems? Specifically, we ask SAFe students to do the following exercise in class, as described in Figure 3-3.
)
Figure 3-3. Agile Manifesto class exercise
The typical response is principles 1, 3, 4, 7, 9, and 12 “work as-is.” The conclusion is that most Agile principles scale without requiring any rethinking for scale. The other principles typically need some further discussion, as highlighted here:
Principle #2—Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. The answer here is largely “it just depends.” This isn’t an attitude problem on the part of the class participants. Rather, it’s a practical recognition that the cost of change for some types of late modifications may create a situation that is 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 of course we want to make that change.
Principle #5—Business people and developers must work together daily throughout the project. For this concept, the spirit is certainly willing. However, there are limitations regarding the economic practicality and convenience of daily onsite feedback from customers of large programs. But we fully respect the sentiment. SAFe addresses this need through certain roles, such as the Product Manager and System Architect/Engineer. We also engage the customer directly at system and solution demos and 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. Attendees always agree with the intent of this principle. And SAFe largely addresses it with periodic face-to-face PI planning events. This probably addresses the majority of needs for efficient communication. However, if you needed a supplier to build a smart power device to fit the physical and thermal constraints of your satellite, you would indeed want to speak to them continuously. In addition, you will certainly want to document the results of those decisions. Fortunately, “working software over comprehensive documentation” does not mean “instead of.” So, most serious Agilists proceed with knowledge of 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 how you define the subject and scope of the decisions. All agree that local decisions are generally best. After all, that’s part of SAFe principle #9—decentralize decision-making. However, that principle also provides the economic rationale for when some decisions are most efficient when they’re centralized.
Principle #11 may be the tricky one, and yet it clearly is the essence of Agile. Let’s test it with a scenario. For example, let’s discuss the User Interface (UI) design for a significant software application, a system where many teams are implementing numerous elements.
If each team made their own local decisions, they would be unlikely to produce a design that supported the significant cross-cutting usage scenarios that they may not even be able to envision. The functions may work, but the usability of the solution may frustrate the customer. For that we’d need a centralized view, which if not created by the teams, would need to be imposed on them. And yet, the role of a User Experience (UX) lead is clearly articulated as an Agile Release Train (ART) role in SAFe. In that case, the best requirements and designs do emerge from the ART team. But, again, it does depend on how you define the team.
In the larger view, decisions as to how the UI would work across multiple platforms in a large value stream may go beyond the limits of ART level design. Those judgment calls may need to occur at a higher level.
The conclusion from this exercise is that the Agile Manifesto does indeed scale, even though some principles require a somewhat expanded perspective. It remains as relevant today as it was when it was written. We’re fortunate to have it, and it plays a vital role in SAFe.