Slotting Wet Agile, SAFe and Spotify in a large scale agile framework
Slotting Wet Agile, SAFe and Spotify in a large scale agile framework
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
This is my third humble strike in the war against the mal-practice of promoting a single model for large scale agile as a one-size-fits-all solution.
In previous posts in this series I presented a few, very different, models for how large scale agile is carried out at different organizations. The large scale agile models vary as widely in character as the products developed through them and the organizations executing them. The first blog post in this series; Exploring the landscape for large scale agile frameworks reviews the Scaled Agile Framework (SAFe) and Spotify’s model and the second one, Wet agile or agile waterfall , covers a mixed method, agile-waterfall hybrid used by Schneider Electric.
One could argue that these models are incomparable. They are incomparable not only because they represent widely different answers to the large scale agile challenge but also because the challenge they address is not entirely the same. It is clear that they have been developed focusing on solving 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 dev. organization, and in Spotify’s case the core thing to address has been enablement of superfast release cycles and team creativity.
So, being aware that I enter shaky ground, comparing these and other large scale agile models is exactly what I want to do. I am comparing them to encourage a shift of the large scale agile debate away from the approach saying “this model is the best because X, Y and Z”, which is scanted by so many consultants out there, to the approach saying “given our situation (product, competition, environment etc.), our large scale agile solution will be inspired by model A and B”. To force this shift I am going to, behold, slot different models for large scale agile into a framework…
Different models for large scale agile- When to use which?
Before explaining the framework, let me again reiterate the core message of this post; There is not a one-size-fits-all solution when it comes to large scale agile models. When figuring out what model for large scale agile would work the best in a particular setting, you’d be well advised to analyze the needs and constraints of your specific case and pick inspiration from the models that have been developed for similar circumstances. What model works best for you will depend on many different things, but there are some key questions you can ask yourself to get guidance and help prioritization among the different large scale agile models.
Three questions that are important are;
- Do you have a lot of intradependencies within your development unit?
- Is it so that no matter how you organize there will always be lots of dependencies between teams? Are your teams working towards a joint release? (as opposed to being able to release independently)
- Does your development unit 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 your development unit?
- Game development and other entertainment consumer products tend to have a high need for creativity and innovation
Picture 1: The axes in the figure describe the development environment; Many vs. few intradependencies, many vs. few levels of interdependencies and high vs. low need for creativity and innovation.
In the picture above, I have been bold enough to slot three frameworks where I think they fit.
- SAFe is well suited for environments in which there are many dependencies between 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 but also one that really works.
- SAFe is suitable when the need for creativity and innovation among the developers is not a top priority. If you believe that creativity and innovation spurs out of team empowerment (eg. the ability for team members to influence the content of work, the process for how they get the work done and their ability to influence the surrounding environment) SAFe should probably not be your choice as it priorities a high-level coordination and alignment of teams above giving teams the freedom to decide for themselves. This is manifested in things such as coordination of the teams’ time boxes, the urge for all teams to use scrum, the lack of protected time slots during which everyone can do work of their own choice etc.
- SAFe works reasonably well for environments with high levels of interdependencies, but has not been designed seeing this as the core challenge to solve.
- Scaled agile @ Spotify
- Spotify has not seen the handling of dependencies between teams as the core challenge when designing their large scale agile model. Their teams (or squads as they call them) are autonomous and has the skill to handle everything from design, development and testing to release and production on their own. Dependencies between squads are relatively few and are handled through scrum of scrums when they occur.
- Spotify’s model empowers the team which favors creativity and innovation among the 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% of his/her 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.
- Enterprise Agile-Waterfall
- This model does not invent new ways for handling dependencies across software development teams but they refer to the practices and roles of SAFe when scaling.
- Lots of unit interdependencies is the core challenge the Enterprise Agile-Waterfall model has been developed to address. The model has been designed to deal with several time fixed milestones that sometimes even originate from different sources.
- Just like SAFe, this model doesn’t score super well 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.
In the framework above, I allowed the parameters; Many vs. few intradependencies, many vs. few interdependencies and high vs. low need for creativity and innovation to be the key guiding questions when searching for suitable large scale agile inspiration. These questions are certainly not the only ones to consider when designing a large scale agile model for a particular context and I welcome the debate about what other questions should be at core. The most important thing however is that the people in charge for creating a large scale agile approach that works at their company realize that there ARE a number of really important questions to consider and avoid getting swept away by the strong lobbies promoting a specific solution. For consultants, there is a lot of money to be made in large scale change efforts like agile transitions. Hence, there is never going to be a lack of guidance in this area. The real challenge is to find unbiased guidance and information.
Opinions expressed by DZone contributors are their own.