SAFe does not create benefits – people do
SAFe (Scaled Agile Framework) is gaining traction as the way to scale the success of Agile and is thus becoming the new way of producing software as well as other types of deliverables fast and efficiently. However, in most cases we cannot exclude “people” as the most important factor when developing products, services, new ways of working or prioritising our scarce resources.
We believe that SAFe can play an important role as a way, or methodology, of solving the problem of how to effectively deliver software – and also many other types of classic deliverables such as hardware, services or processes.
However, we also believe that these ways of solving the delivery problem have the same great risk of failing to deliver benefits as the waterfall model. SAFe, Agile and PRINCE2 for that matter are born to solve the delivery problem, and even though all of these frameworks mention benefits, organisational change or building competences, this is not their core, and it is not what they do best.
Acknowledging that SAFe can solve the delivery problem for many organisations, we still need to solve three problems with SAFe in order to actually create benefits.
We acknowledge that if you are Spotify or a similar type of company that lives off software, or if you do not have a large organisation that needs to use what you are developing, then these problems might be insignificant. When you launch a new product, service or a more efficient way of working, these are real problems for the large majority of companies and organisations where people actually need to work differently.
SAFe portfolio management aims to realise the strategy by delivering a series of epics. An epic is an initiative that delivers a solution (deliverables) and has its own analysis and SAFe’s Lean business case. If you are not a SAFe evangelist, think of it as a project that builds a product, service or something to support future products or services.
In other words, problem #1 and problem #2 are caused by the fact that SAFe as well as Agile and classical waterfall-based project development frameworks focus on the strategy/purpose and on the production of deliverables, which leaves a “black box” in the middle.
The figure below illustrates the benefits realisation process and thus the cause and effect relationship which we need to establish in order to succeed in creating value from our deliverables.
The solution to problem #1 SAFe has an ‘IT inside-out’ perspective on benefits that does not create ownership of benefits in the business and problem #2 SAFe leaves out building competences and changing behaviour in the receiving organisation is to apply benefits realisation to SAFe by developing benefit maps (see the post The key tool for benefits realisation for an in-depth description of the benefit map) as part of the epic analysis and as the basis for the business case.
The great thing about solving problem #1 and problem #2 is that they enable effective portfolio management and thus solve problem #3, because now you have reliable benefit estimates and reliable cost estimates that also include costs for competence building and behavioural change, as well as a benefit map that will help decide when to keep developing solutions (deliverables) for an epic and when to stop and focus your energy and money elsewhere.
We think that SAFe is an immensely interesting way of tuning your development engine for many organisations, and we also think that we need to add a benefits realisation layer to make sure that our investment in products, services and processes creates the value it should.
If you agree, disagree or have questions or ideas, please do not hesitate to write a comment, contact us on LinkedIn or write an email to Rasmus Rytter
Article in German: Five principles of how to design successful change communication that will create impact in your organisation.
Implement Consulting Group