So when should you not use safe?
When will it hinder do you?
When will it go against your organisation’s culture?
After working in nearly 20 organisations from digital media to software vendors to corporate IT we believe we can provide some evidence of where it should not be used as well as where it should be.
What is SAFe Sweet Spot?
Without doubt SAFe is great for large B2B software vendors with multiple teams that need to collaborate to build large things together and thus contribute to a single product, delivering periodically throughout the year.
SAFe may also be appropriate for large B2C vendors but only those that do not need to frequently test and validate consumer assumptions and can thus release infrequently. E.g. large games or large office applications. If the enterprise needs fast turn around and short customer learning cycles then SAFe will slow you down.
(p.s. we spoke about this in September 2014, at the GotoNight in Zurich. The slides are available from SlideShare here.)
Where else can be used?
It could be used within corporate IT. Especially where Scrum and Kanban have got a foothold, where the question of project management has been addressed, where Agile mind-set is mature and where IT is seen as an enabler for product support and development.
Where should it not be Used?
In corporate IT environments that are populated with project managers following the PMI, Prince2 or Hermes and where Agility is not yet established. Bringing in SAFe will just make it harder!
Why? Clearly SAFe is a product development framework, not a project framework.
For example, an insurance company’s corporate IT have large, complex, multi-platform systems that support the launch and administration of, for example, life-insurance contracts. The insurance company’s products are the contracts, not the underlying IT systems.
Scrum and SAFe are designed for software products, not corporate IT project cultures.
And it is for reasons such as these that we often see clashes of Agile and culture. A recent survey in Switzerland by SwissQ showed that 50% of Agile adoptions are unsatisfactory. The two main reasons were cited as 53% for lack of control and 71% because of the culture. In addition, the famous VersionOne Agile Surveys frequently state that Culture is the Nr 1 barrier to Agile adoption.
Thus, forcing a product development method on a project culture is going to be hard. To ease the Agile transformation, start with DSDM. Once that is established, look at SAFe again.
There are also software venders with large systems that are for consumers. E.g. Spotify, Skype. Yet these products require frequent updates and A/B testing so the SAFe Release Planning cycle will slow down that life-giving feedback.
It is also inappropriate for digital media, for the same reasons listed above.
In both cases use Scrum to start with and then once mature, move the teams to Kanban as Sprint Planning will become waste.
Are you considering SAFe?
Want to know more about our experiences? If so, then contact us. We’ll be more than happy to hear from you.