Agile At Scale: 3 Methods That Work (And Why)
The interest for large-scale Agile transitioning programs is booming as lean and Agile development methods continue to deliver on their promise. In turn, convinced decision makers in organizations pour more funding into transitioning programs. In this post, we’ll examine the evolution of Agile transitioning programs and survey a few available large-scale Agile development models. Finally, we'll look at why one might favor a particular model to use in their own organization.
The History of Large-Scale Agile Development
With increased buy-in at the executive level, we’re seeing more full-blown change initiatives than the typical gradual transformations seen previously. Early Agile transitioning programs (if it is even right to refer to them as “organized programs”) were often small pilot projects. In which, individual development teams experimented with lean and Agile methods. When a team arrived upon a method or process that worked particularly well in their context (commonly an adapted version of scrum), the organization would then try to spread best practices internally while scaling the process to fit existing processes on the program/product level.
In comparison, today’s approach to transition looks very different. The scope of Agile transformation programs are expected to impact not only the development organization but the company as a whole and its customer interface. The mandate of change agents have grown. They’ve moved beyond changing the way we think and work in the development organization and transformed into the redesigning of major parts of the company. This translates to changing reporting lines, relocating people, rebuilding the office space, and doing whatever it takes to get the company to a more Agile state. The end goal, of course, being to streamline work processes in order to outperform competitors.
Needless, managers in these ambitious organizations often feel challenged to come up with (let alone implement) a smart model for scaling Agile that aligns with their company’s products and contexts.
They then turn to the industry for inspiration…
[RELATED CASE STUDY: How One Company Scaled Agile (SAFe + LeSS) With Hansoft]
What Agile at Scale Models Exist?
So, what frameworks for Agile at scale are out there? What types of product development and environment do they address most successfully?
It can be difficult to find an answer to these questions. There are few forums presenting and exploring the pros and cons of different frameworks. As a result, many Agile coaches and process consultants tend to specialize in one model and promote it as a one-size-fits-all solution.
Below is not a comprehensive and detailed list of all existing models Instead, it is a range of options available to implement Agile at scale. It is intended to be a starting point, a source of inspiration.
Scaled Agile Framework (SAFe)
Let’s begin with the most obvious option familiar to many large software developing/engineering company: Dean Leffingwell’s scaled-Agile framework.
- Framework is open source and constantly evolving.
- Describes roles and practices across team, program and portfolio level.
- Optimizes for program, not team level.
- Emphasizes close collaboration and alignment between top-level management and development organization.
- Solves core challenges of large-scale Agile — dependencies between work packages conducted by different teams —through up-front release (PSI) planning.
The Spotify Model
Spotify provides a digital music service with access to millions of songs. Their development organization consists of 30 teams that are spread out in three different locations. In 2012, Henrik Kniberg and Anders Ivarsson published a paper of the large-scale Agile at Spotify — a model that has received much attention and been an inspiration for many.
- Approach is team-centered (or “squad” as Spotify calls them).
- Squads are cross-functional and autonomous (capable handling everything from design, development and testing to release and production on their own).
- Squads are empowered to organize their own work and ways of working (Scrum, Kanban, and hybrid are used).
- Dependencies between squads are few and handled through scrum of scrums when they occur.
- Continuous learning and innovation is handled in the format of “hack days” and group belongings (chapters and guilds) based on skillsets and interests.
Another approach to scaling is to create an Agile-Waterfall hybrid, as companies such as Schneider Electric have done. It’s particularly appropriate for enterprises creating a product with a combination of hardware and software components.
- Their model allows software teams to adapt Agile practices, while hardware development (and overall product management) use a traditional Waterfall approach.
- The resulting (and very challenging) product backlog management situation is well-addressed by the model. It accommodates swift product releases by attending to feature releases planning on the software side.
- Compromise is critical. Like any other hybrid model, this Agile-Waterfall hybrid compromises some of the principles of non-hybrid methods. The Waterfall side of development lives with flexibility regarding software requirements. Likewise, Agile teams must commit to time-fixed delivery dates, cost forecasts and risk assessment.
One could argue that these models are incomparable. Not only because they represent widely different answers to the large-scale Agile challenge, but also because the challenges they address are not entirely the same.
Clearly, each was developed to solve different core problems. In the case of SAFe, this would be ensuring coordination and alignment of effort across team, program, and portfolio level in the development organization. In Spotify’s case, the core challenge we need to address is to accelerate release cycles and boost team creativity. In the enterprise Agile-Waterfall hybrid, we need to find some compromise between the requirements for creating hardware and those for developing software.
Large-Scale Agile Development Models — When to Use Which?
Remember, there is not a one-size-fits-all solution when it comes to large-scale Agile models. When deciding what large-scale Agile development model works best in a particular setting, analyze the needs and constraints of your specific case, then pick inspiration from the models developed for similar circumstances. What model works best for you will depend on many different variables, but there are some key questionsyou can ask yourself to get guidance and help prioritization among the different large-scale Agile models.
To choose the right model, consider these three important questions.
Does development have many intradependencies?
No matter how you organize there will always be many dependencies among teams? Are your teams working towards a joint release (as opposed to being able to release independently)?
Does development have a lot of interdependencies?
Are the conditions surrounding your development too rigid or inflexible to allow for non-time fixed releases? For embedded software and products containing both HW and SW, SW development tends to have lots of interdependencies. The same is true for distributed development and rigid contract development.
Is there a high need for creativity and innovation in development?
Game development and other entertainment consumer products tend to have a high need for creativity and innovation. How they scale Agile must account for that.
Based on these criteria, we can roughly place these three frameworks into their most appropriate conditions.
The axes in the figure above describe the development environment: Many vs. few intradependencies, many vs. few interdependencies, and high vs. low need for creativity and innovation.
High Dependencies, Low Need for Innovation
SAFe is well-suited for environments with many dependencies among teams. Practicing SAFe means spending considerable time and resources to plan and coordinate work in release/PSI meetings. This is a costly way of handling dependencies and alignment between teams. Yet, it really works.
SAFe is most suitable when the need for creativity and innovation among the developers is not top priority. If you believe that creativity and innovation spurs out of team empowerment (for example, the ability for team members to influence the content of their work and decide how they get the work done). SAFe should probably not be your choice as it prioritizes high-level team coordination and alignment over giving teams freedom to decide for themselves.
SAFe works reasonably well for environments with high levels of interdependencies, but has not been designed seeing this as the core challenge to solve.
High Need for Innovation, Low Dependencies
Spotify has not prioritized dependency resolution as a core challenge. Their teams (or “squads” as they call them) are autonomous and capable of handling everything from design, development, and testing to release and production independently. Dependencies between squads are relatively few and, should they occur, handled through scrum of scrums.
Spotify’s model empowers teams that favor creativity and innovation among developers. The teams organize their own work and ways of working (eg. Scrum, Kanban, and mixed methods are used). Spotify’s model also encourages the developer to spend 10 percent of their time on “hack days” (which surely spurs creativity).
Spotify’s model is not design to primarily answer specific demands from the surrounding environment such as time fixed releases. Their light weight model is certainly one that allows for rapid release of customer value but what the release contains and when it happens is dictated by themselves and not set-in stone through contracts with someone else.
High Interdependencies, High Need for Innovation
This model does not invent new ways for handling dependencies across software development teams, but refers to the practices and roles of SAFe.
The Enterprise Agile-Waterfall model has been developed to address challenges from many unit interdependencies. It can handle several time-fixed milestones (that sometimes even originate from different sources).
Just like SAFe, this model doesn’t score high on the creativity/innovation parameter. The need for teams to commit to numerous fixed milestone dates is hardly something that boosts creativity among the team members.
Bringing It All Together
In the framework above, we used three key parameters: intradependencies, interdependencies and need for creativity and innovation. These parameters are certainly not the only ones to consider when designing a large-scale Agile model for a particular context. The most important thing, however, is that those charged with selecting and creating a successful large-scale Agile approach be aware that there ARE several questions to consider.