For Business Agility, Stay SAFe Or Scrum At Scale?
Business agility has become the need of the hour and the number of organizations wanting to go agile or do agile right has exploded in the past few years. The cover page of the May, 2018 issue of the Harvard Business Review (HBR) boldly proclaimed “Agile at Scale” [1] and gave executives a path forward to mastering large-scale agile initiatives. Exactly fifteen years before this issue was published, HBR had guided executives saying “IT doesn’t matter” [2]. We all know what has changed in the past two decades — start-ups and platform model companies have shown that technology is not a commodity, but a strategic differentiator to scale and dominate in the twenty first century economic landscape.
As established organizations begin to shed their old ways of working and looking to become agile, they face challenges on how to be agile. It’s not all about bean bags and free pizzas for sure. In this context, Scaled Agile Framework (SAFe) has become popular with executives globally and has been adopted by 70% of the Fortune 100 companies [3]! However, there has been some criticism against this ‘framework’ and the detractors say that SAFe is not truly agile. They recommend sticking to core principles of agile (e.g., scrum). So, what’s the path forward if you want to be agile at scale — choose SAFe or try scaling the scrum?
Imagine a friend at the doctor’s office who has recently been diagnosed as diabetic. The diabetologist typically offers the patient two options after reviewing the haemoglobin A1c levels. One is to get on a strict prescription regime to bring the sugar levels down and the other and more difficult option is to shift to a holistic lifestyle change — from everyday diet, meditation to manage stress levels and daily exercise. The two choices for business agility are very similar to these two options. Go with a very prescriptive SAFe approach to run a dual operating system [4] where you retain the hierarchy and yet launch ‘Agile Release Trains’ to achieve customer centricity and rapid delivery at scale. The second path to agility is more difficult. It needs agile evangelists with the missionary zeal to transform a large bureaucratic siloed organization along with the top leadership modelling the lean agile principled behavior.
At Publicis Sapient, we have helped companies adopt SAFe, adapt SAFe to their environment and also move away from SAFe to truly agile ways of working. From our work advising and delivering business and product agility for these companies, we have discerned three crucial stages that leaders should understand if they want to scale business agility in their organizations.
1. Adopting the SAFe way forward
In 2010 and much before the advent of SAFe, I worked with a US-based retailer and we launched agile trains to deliver the prioritized business requirements. Each agile train (or ART in SAFe lingo) consisted of multiple scrum teams (aka compartments), left the starting station at a predetermined time, and arrived back at a future date. Just after two quarters, three major benefits were achieved. One, the business got predictability of when they would see features going live. Second, the IT organization could plan capacity in advance based on the trains being planned and loaded by the business. And finally, the teams loved the autonomy, and for the first time, we saw an innovation backlog from the Engineering teams which generated additional revenues. Before the transformation to agile trains, this retailer was considered a laggard and slow to react to market conditions while a few quarters into the journey, the results were indeed transformational.
In our experience, those are typical preconditions for any organization wanting to adopt SAFe. Everyone needs to get organized around value delivery and want to deliver the most valuable features faster than anyone else.
2. Adapting SAFe to context
A leading financial services client based out of London has been at the forefront of digital business transformation and reinventing its age-old practices and culture to lead even the nimble fintechs. What has been fascinating to watch is, how they have interspersed SAFe along with several other lean agile practices, creating unique ways of working which are delivering these transformational outcomes. As an example, the teams felt that once in three months Program Increment (PI) planning as prescribed by SAFe was not enough. So instead they have adapted the PI planning to be a monthly planning exercise typically lasting six hours. The results show that they have been ‘responding to change’ faster than ever before.
With both SAFe and scrum methods, teams are realizing that while you need agility at team levels, you also need agile interactions between the teams to speed up the ‘idea to live’ backlog. Another learning has been that kanban at team level is not as important as managing the portfolio kanban. A few companies in Europe have started adding “Flight Levels” on top of their Agile Release Trains to deliver faster time to market [5].
When companies start their transformation journeys, we have seen the prescriptive recommendations made SAFe adoption more palatable to them. However, as teams discovered the true power of agility, they began evolving the practices and experimenting with newer recommendations to ultimately adapt it to suit their context better.
3. Moving beyond SAFe
Many of our clients have moved beyond SAFe for a wide variety of reasons. A US-based retailer saw fantastic results [6] with SAFe adoption, but then an organization-wide leadership change happened. The new leaders were not familiar with SAFe; unconsciously most of the essential elements of the SAFe framework were compromised, and in about a year’s time, they became very ‘unsafe’!
A large hospitality chain, stumbled the first time with the initial implementation of SAFe. Second time, they got the framework and practices right but only for a small part of the organization. No tangible results were achieved as the rest of the organization continued to function as before, and eventually they moved away from SAFe completely. Yet another financial services organization had two power centers — one with the technology team which was pushing for SAFe, and the other within the innovation team which was rooting for pure scrum. While the technology leaders won the first round and went all in with SAFe, the teams lost both velocity and time-to-market after the adoption. Since then, they have chalked out a way to scale scrum [7] which takes inspiration from the Scrum@Scale framework.
In the examples above, we have found the emergence of agile evangelists who know that the challenges of tomorrow cannot be solved just by the methods from the past, that the agile mindset is not a destination but a journey, and that they need to forge their own paths if they wish to disrupt and lead the marketplace.
In Summary
The two tipping points quoted widely for SAFe adoption are ‘burning platform’ or a crisis which is threatening the company’s survival and a visionary leadership who know that they have to drive to change proactively. In an internal survey of SAFe Program Consultants (SPCs), a third reason came to light on why companies are adopting SAFe — there is no alternative! Critics will argue that the relentless marketing by Scaled Agile has resulted in this blind spot and that SAFe framework is not even agile. While the proponents of SAFe will talk about business results they have delivered, and how there is no one “Spotify model” for success anywhere else.
Just as the doctor will ask the patient with high sugar levels to start with a drug regimen and in parallel start the lifestyle changes, the agile maturity of an organization should dictate if they should adopt SAFe immediately, adapt SAFe for their context or evolve their own path to scale agility.
References:
- HBR: Agile at Scale — Harvard Business Reviewhttps://hbr.org › 2018/05 › agile-at-scale
- HBR: IT Doesn’t Matter — Harvard Business Reviewhttps://hbr.org › 2003/05 › it-doesnt-matter
- SAFe Adoption: https://www.scaledagile.com/enterprise-solutions/what-is-safe/
- Dual operating system is radically different from bi-modal IT (from Gartner) and two-speed IT (from BCG) which were popular few years back.
- What is Flight Levels: https://www.flightlevels.io/flightlevels/
- Results for the US retailer … time to market stats to be updated.
- Getting started with Scrum@scale: https://www.scrumatscale.com/scrum-at-scale-guide/
Author: Ramprasad Padmanabha, Vice President Product Management
