Six Changes I'd like to see in SAFe

(SAFe Big Picture, from www.scaledagileframework.com)

Inspired by Ken Clyne’s great list of ways to avoid common pitfalls in implementing SAFe (Avoiding the Pitfalls of SAFe (fivewhyz.com) ), I commented that I had a list of things I’d change; he invited me to write them out, so here goes.

I’ll break them into three buckets and do a quick post on each one. They are:

1. Changes to the Big Picture;

2. Changes to the Implementation Path;

3. Changes to the ‘business wrapper’ of core SAFe and the ‘SAFe industry’

Let me talk about what I’d change in the Big Picture (basic model of SAFe) first.

I’ve commented in the past that I see a few gaps in the overall SAFe model which makes it far more push- than pull-driven, and that on one hand make it more digestible for managers in hierarchical organizations (not always bad…) but also limit it as what someone called ‘a bootloader for change.’

• First, and foremost, there’s no formal ‘change-driving process’ in the BP itself. There are ‘work management’ processes and the beginnings of some ‘customer-centric’ processes – but really nothing (yes, I know about the I & A sprint) powerful enough to serve as an engine for change.
  
  I’d do two things – first, I’d borrow from Rob England’s model and staff a ‘change office’ and build a cadence for ‘change work’ that parallels and feeds the overall work intake process. I’d derive that change work in two ways – first, by explicit feedback processes from customers (internal and external) and workers, that would feed a strategy planning process focused on change and improvement. This change and improvement ought to be explicitly about two things: products and processes (what are we delivering, and how are we delivering it).
  
  I’d build in guardrails at each level and allow for levels of experimentation with certain things and systems that must be preserved (financial reporting, work management tooling, etc.). So we’d have explicit cadences for feedback and for assessing that feedback and both setting strategic goals/OKR’s and setting aside capacity to achieve them.

• Second, I’d make explicit ‘change capacity’ a part of portfolio planning along with architectural runway – so that we’re continually setting aside capacity for change as appropriate, alongside capacity for technical improvement.

• Third, I’d recast LPM as ‘capacity planning first’ – meaning I’d make the planning cycle one in which we measure, plan, and allocate capacity (which is a way of handling the ‘lean budgeting’ icon in SAFe LPM) and then parse work and fill the available capacity.

• Fourth, I’d create a set of ceremonies that tie the ART PM’s and PO’s (and, ideally the teams themselves) into some conversations with customers so they have some line of sight to the users of their work.

• Fifth, I’d shift from ‘value-streams’ in complex internal-serving organizations to Yakyma’s ‘outcome chains.’ I’m convinced that the rubrics for value determination for internal work are just too fuzzy and don’t lead to optimal ART design. We wind up with a lot of ART’s of ‘120 people who work in the same group’ because the value chains are too hard to trace.

• Sixth, and finally, I’d explicitly weave OKR’s and OKR management/review into the model. We’re setting team and train goals per PI; these are useful (if done above a lip-service way…) but I think we’d be much better served with real business OKR’s for solutions, trains, and teams.

I am adding some headcount with this, in the form of a ‘product/process change’ team, but it’s not going to be very big, and ideally, we’d staff it with the people who helped stand up the ART and then morph their roles.

We’re adding two processes: One to gather product/process improvement ideas, and one to connect customers back to development or operations.

We’re adding complexity two ways: by adding the capacity conversation to LPM and by adding formal OKR’s to team and train planning and review.

But it seems to me that these burdens would deliver a lot.

• They would shift the model from one the manages the flow of ideas and work downward (bosses decide, workers execute) – which is one of the strongest complaints I hear about SAFe - to one where there is the beginning of a cycle that allows the folks doing to work to shape it.

• They would make change and improvement first-class citizens in the management system.

• They would improve train design by tying it to outcomes – which can and should be much clearer than vague internal increments of value.

• They would integrate explicit feedback (in the form of OKR’s) into the processes.

I’ve thought about these for some time, but just quickly jotted them here - there’s clearly room for clarification and improvement. What do you think?