Do agile principles work at scale Part 2?

In part one of this two-part blog series, I examined the challenges and opportunities for applying the first 6 guiding principles of agile at scale, looking at some of the frameworks that are designed to help organizations address this challenge. Here, I’ll discuss how organizations can stay true to the remaining 6 guiding principles, even with teams of hundreds or thousands of members.

7. Working software is the primary measure of progress.

This is still the case at scale, but more demos are needed than just team demos. When you have a dozen teams building a solution, it physically is not possible for a stakeholder to get to all of the team demos. The Scaled Agile Framework® (SAFe®) has specified the system demo to solve this problem. This is a feature level demo that allows all stakeholders of the agile release train (ART) to come to see working features. The system demo is also a forcing function for integration. 

8. Agile process promotes sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

This also is still the case at scale, but this principle needs a slight adjustment even for single teams. My experience is that teams who just sprint, sprint, sprint get “sprint fatigue.” I have talked to many other coaches who see the same thing. This usually starts setting in after four or five sprints. SAFe has the innovation and planning (IP) sprint. I promote this sprint for single teams. It creates a change of pace and gives the team built in time to innovate and plan for a longer horizon. This is a very busy sprint with critically important work taking place, but it is different from their other sprints and provides that needed break from the routine.

9. Continuous attention to technical excellence and good design enhances agility.

At scale, this principle holds even truer. The big ball of mud becomes a pool of quicksand that stops progress completely. Agile without good quality practices just gets you more quickly to this dead end state. Quality must be built in at scale. You can’t have separate test people who try to inspect quality in. Test-driven development (TDD) and behavior-driven development (BDD) become even more important at scale.

10. Simplicity  ̶  the art of maximizing the amount of work not done – is essential.

As in principle 9, this statement is even truer at scale. The amount of work not done needs to grow exponentially as the scale of the solution grows. One of the most significant wastes is working on features that don’t really add value or are never used. Therefore, agile team leaders must constantly re-evaluate their backlog with an eye for which features will add the most value (and which ones won’t).

11. The best architectures, requirements and designs emerge from self-organizing teams. 

At scale, this can be a disaster if you do not collaborate and work within constraints. If every team did whatever they thought was best for them, you would have five different versions of the same library, different tools for the same functions, etc.  The teams must work together to agree on architectural decisions. In SAFe, this is the role of the system and solution architect, to provide the guidelines and communicate direction. The teams still must emerge their architecture, but by working within these constraints.

The common approach among frameworks at scale is to ensure that there’s an active conversation among multiple teams and consensus on the overall approach. Exploration is encouraged. This active conversation not only avoids risk, but also ensures that the successes and discoveries can be adopted by others in the event there’s an opportunity for common alignment. The methods to support this alignment ranges from cross-sections of competencies among multiple teams (e.g., “communities") to establishing an enabling role to facilitate the needed alignment and consensus. At the end of the day, a rising tide lifts all boats, but each boat must be in constant communication with the other in order to understand their respective approach to greater buoyancy.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

No change is required for this at scale; you just need to add to this how to do this for teams of teams for those things that are endemic to all of the teams. This is the purpose of the inspect and adapt workshop (I&A) of SAFe. It is the ART retrospective. It has a program-level perspective to address higher-level problems that, if corrected, would have an exponential impact on improving the performance of all the teams. This includes things such as better test environments, delivering pipeline tooling, better feature analysis, and so on.

So, agile principles do work at scale, but the small team methods for applying them must be supplemented or in some cases adjusted. Having the right approach and framework for scaling is essential to success.