Cracking SAFe

safeEvaluating whether the Scaled Agile Framework (SAFe) could be something to experiment with in your organization? If so, here is a personal view.

If you want the one line summary: fundamentally flawed but will add value in most organizations.

Hats off to Dean Leffingwell et al. for “making early and meaningful contact with the enemy.” The product isn’t perfect but they have got it out there and are getting feedback from the market. Now the SAFE authors need to demonstrate their agile credentials by rapidly iterating this product to become even better. I hope that the market success the framework currently enjoys will stimulate a period of rapid innovation in approaches to “scaling agile,” both within and outside of the SAFe framework.

The good

  • Defines a program level heartbeat. The program layer in SAFe provides a way of scaling up scrum – a sort of scrum for a team of teams. It provides roles, events, artifacts etc. for this level of activity.
  • Encompasses lots of other valuable frameworks. Much of the agile good stuff appears somewhere: most of extreme programming, an adapted version of scrum, some kanban stuff, some devops and a nod to lean product development all appear somewhere. It’s good to get an overview picture of this.
  • Acknowledges the realities facing many companies. SAFe proposes, for example, a releasable product at least every 3 months, which is perhaps a more realistic target for many enterprises than scrum’s every 1 month or less.
  • Its probably a lot better than what most companies are doing Agile thought leaders might deride SAFe because it represents a step back from where their thinking is. Yet it could well be a mega-step in the right direction for the people it is aimed at: large companies struggling with large scale software development.

The bad

  • Assumes big is beautiful. The SAFe approach assumes you have a program of 5-12 teams. There is no solution proposed for a 1-4 teams. There is no questioning of whether you need this many teams or what you can do to reduce the number of teams over time. There is broad agreement that scaling the number of teams up from one is the very last thing you should try when you are really out of other options. In SAFe there is no encouragement or support for smaller programs.
  • Stomps on scrum. SAFe talks a lot about scrum but breaks the core scrum rules that: a) the product owner is one person (in SAFe the product manager shares some of this role), b)a potentially useable product is produced within a month (SAFe says 8-12 weeks) and c) there are no dependencies outside a team of 9 people or less. Many companies struggle to implement these but at least with true scrum, they know at least know where they should be heading. A real fear is that companies will do SAFe because they don’t have the courage to do scrum. Consequently they won’t really get much juice out of the agile revolution.
  • Not much help for getting from here to there SAFe is so massive and sprawling that it is hard to know what is important, where to focus first and what we can leave to later.  There is no process for the adoption of SAFe. It seems like it’s implied that it’s a big bang – i.e. SAFe framework adoption is not an iterative adaptive process in itself. Where is the inspect and adapt activities on the adoption of the framework itself? There is no help for the organisation to “uncover better ways of developing software
  • Prescriptive tone SAFe says… Do this. Do that. Very little of how it is set up refer back to any underlying principles. It’s also a one size fits all model. SAFe is rooted in the experience of its authors and the tone is authoritarian.  Like all of us, they have limited experience. How many companies have they really implemented all of this with? Contrast that with the work of Larman & Vodde who present their experience in fairly humble tones as patterns that worked for them that others could try.

The indifferent

Some minor gripes…

  • The top (portfolio) layer is pretty thin. The portfolio layer is a valiant attempt to complete the enterprise picture. In most companies, how projects and programs get started is a murky political affair. Initiatives with significant backing will always circumvent defined processes. I see projects and programs as being like laws and sausages – its better not to see them being made. I can’t see how imposing a simple standard process model at this level adds any value.
  • Weighted-shortest-job-first prioritization is not implemented correctly. This economic approach and as such the cost of delay needs estimating in $ or £ or whatever. Relative estimation of cost of delay is just wrong. This gives no information to the team(s) what the company might be willing to pay to expedite the work. Using relative values is the easy way out.
  • Not clear what is and isn’t in SAFe Is it a toolkit? A source of inspiration? When can I say I am doing SAFe? Not clear.
  • Process over Individuals & Collaborations SAFe does have values like transparency and alignment but most of its thrust is around the big process -which doesn’t seem terribly agile. This is also, ahem, a criticism you could make of scrum – yet scrum says so little this can easily be justified as “just enough process”. The process picture appeals to management. Is this just pandering? Giving them what they want, rather than what they need?
  • Slow (8-12 week) program adapt & inspect This seems an awfully long learning loop. Contrast this with Larman & Voddes Framework 1 & 2 which have joint sprint retrospective at the end of each sprint.
  • Responsibities between Scrum teams, System team and DevOps.  As written, it seems like the DevOps team is the Ops part of DevOps and the System team is the Dev part. Doesn’t feel like true DevOps. Also, the system team seem to have a lot of responsibility for testing the system etc.  This will promote a lack of ownership of system issues in the scrum team.
  • The different agile approaches in SAFe don’t join up. The SAFe training material includes, for example a summary of lean product development (e.g. batch sizes, queues,…) yet this work is rarely cross referenced in any of the other chapters.

 

Leave a Reply