The Need Of Scaled Agile Framework
20 years back, when Agile and Scrum was introduced, the need was for a team to work together and deliver value to the customer frequently. However, there is a drastic change in the industry that demands not just agility, but there is a clear need for scaling agility to a large program of 100+ people and beyond.
In today’s world, agility is required at the team level else we will be out of business. HOWEVER, IS THAT ENOUGH? Definitely No. Except for startup teams where the one team builds a product end to end, most of us work as a large team to build and release a product to our customer. So, Agility ALONE is not enough. We need to think about how to scale agility and sustain it.
There are 2 basic challenges in Agile frameworks when required to Scale.
- Scrum is for 1 single team:
The moment more than 2 or 3 teams start working together to build one product, the Scrum framework doesnâ€™t know how to execute it. Scrum is all about 1 team delivering value to customers often. While Scrum is one of the best agile frameworks for a team, it doesn’t know how to execute a program when more than 3 teams need to work together.
- Failure reasons in scaling agility
Failure in Scaling agility happens due to predominantly 2 reasons.
- Agility is not in place at a team level. What does it mean? The team doesn’t follow agile in terms of processes and practices – ex., Scrum not followed as defined, engineering practices like automation / TDD / review / DOD are not implemented, etc. When the agility is not in place, scaling will be a disaster. Scaling agility will fail when the foundation (Agile) is not set right
- Even if the teams are good agile teams, the chances of failing in Scaling is still high. What if the teams working together donâ€™t collaborate on dependencies? What happens when the definition of quality is not common for all the teams (DOD)? What if the backlog is common for the program and each team goes on their priority?… Like these examples, there are many situations that good agile teams can still fail if scaling is not taken care of.
So, the summary is â€“ Chances of failing in Scaling agile is much higher and much more expensive than a single agile team failing.
What is the solution?
The only good option to resolve scaling agility is following a very robust, proven framework in the industry. Agility is not enough. We need to bring the best practices from other proven industries like the automobile. SAFe is the best and proven â€śLean-Agileâ€ť framework for scaling projects/programs.
How do you achieve business agility using SAFe?
SAFe is not just an Agile framework. Itâ€™s a â€śLEAN-AGILEâ€ť framework, which brings a lot of great lean practices into product development. Here are few examples of lean and agile execution in SAFe, that bring in true business agility in a scaled environment.
- Value delivery through Value Stream focus:
Lean is all about value delivery and SAFe has borrowed this wonderful concept of Value delivery focus. Itâ€™s all about delivering value in a sustainably shortest lead time. This also helps to look at the entire system (systems thinking) and improve the value stream. For ex., look at the below picture that depicts the release cycle of a single feature.
Total lead time for a feature is 6 months and 3 weeks
Total time for execution is 3 weeks
However, total time in waiting is 6 months
Looking at the situation, where should we focus on to improve the release cycle? Not on the execution effectiveness, but on the waste removal (the red items). Just by focusing on waste removal, the product release cycle can be improved by multiple times.
SAFe mandates building DevOps culture to achieve the fastest delivery culture.
- Effective Program Execution through Systems Thinking
Though the teams are good agile teams, we need to bring common disciplines across the program so all the teams under the program work together effectively. Here are a few examples of effective program execution.
- Align Cadence and synchronize teams â€“ All the teams working under the SAFe program align with the same release/sprint cadence and collaborate constantly on common points like managing dependencies, feature delivery cycle alignment, manage common risks across teams and eliminate them, etc. These will improve the efficiency & effectiveness of the program to multifold.
- Execution of Common agreements â€“ Teams under the SAFe program has common agreements like common Definition of Done (DoD), backlog structure (ex., user story format), common architectural guidelines for all the teams (architectural runway), common engineering practices (like automation strategy), etc. This is critical for the program to be successful.
- Program roles to focus on program execution â€“ SAFe defines very clear program roles to bring systems thinking at the program level to bring effectiveness and efficiency.
- Product Manager (PM) role focuses on building vision, roadmap and program level backlog.
- Release Train Engineer (RTE) focuses on bringing agile practices effectiveness and program increment (PI) execution.
- Architect focuses on building long-term architectural runway as an intentional architecture that guides the team to take correct design decisions.
- System Team focuses on the end-to-end system integration and makes sure the system is working as-a-whole.
SAFe drives built-in-quality right from the team till solution integration. For ex., DoD is defined at various levels like Story DoD, Feature DoD, Solution DoD, etc. At each level, the quality is validated thoroughly before it goes to the next level of structure. This enhances the product quality to be very stable right from unit-level till the end to end solution.
The other example of quality is backlog quality. SAFe makes sure that backlog is of high quality with clear vision, roadmap and with absolute clarity at least for 1 Program Increment (PI).
Common Engineering practices drive quality common across the program.
- Team Agility â€“ the best way to build product incrementally
SAFe strongly drives agility at the team level as Agile is the way to go for building products incrementally. Team level agility is key to building products incrementally within and at the end of every sprint. Every team in a program follows a 2-week iteration that has all the events â€“ iteration planning, iteration review, iteration retrospective, and daily stand-up.
This builds WE culture, Incremental Delivery culture and Fail fast culture at each team.
The above list is not the final list of reasons for bringing the agility, they are a few of the key reasons to bring business agility in a scaled environment.