When is SAFe® safe?

 Image on slide presented over my head in this photograph is from the
Reinventing Organizations book by Frederic Laloux

When is SAFe® safe?

I refer to the Scaled Agile Framework® as per www.scaledagileframework.com. The Scale Agile Framework® website does a much better job of describing SAFe® than I ever could. This article assumes prior knowledge of SAFe® and related topics. 

I am an agility transformation partner. I take many large training class bookings, as I get energy from people and it balances my transformation work. I got together with Nader Talai. In Value Glide, we developed our unique integrative approach for agility transformations. It’s been around since 2010 and evolves every month. It came of age in 2015-2016. It’s proven, and we have results for anyone to see. The approach is context-dependent. The deal breakers for “I am the Change” are the acceptance of WaterScrumFall as a good way of doing things, lack of appetite for DevOps, and lack of appetite for Lean Finance. We bore people about it at our conference talks, so I won’t bore you now :). 

For a long time, I was deeply unhappy about the Scaled Agile Framework®. I reviewed all available patterns in 2012, but I never published that work. Let’s see if I update that for 2017. And I’ve been researching synchronisation patterns ever since, along with transformation patterns. 

But, I’ve got to give the SAFe® methodologists some credit. SAFe® is on version 4, and it feels fleshed out. I feel sad when I give Scrum courses to organisations who insist they need Scrum when I can see they’re not yet set up for even starting it. I want training attendees to feel satisfied. To cope with this, I add one day to my Scrum courses, partly for Monte Carlo probabilistic forecasting tools at www.focusedobjective.com by Troy Magennis, and partly to spend ½ day on the Kanban method and /or some discovery methods. And, because many teams working together will need more options to synchronise work, I expose my training audiences to Nexus, the exoskeleton of Scrum (which I can use to synchronise Kanban team also, with Ken Schwaber’s permission; and the Lean Start-up for that matter). I also expose audiences to SAFe® on the Scaled Agile Framework® website (to avoid a breach of copyright), LeSS, Disciplined Agile 2.0, what Spotify does, and Mike Cottemeyer’s blog posts on scaling. Indeed, I also cover the network effect, not using any scaling pattern. Hence, I refer to synchronisation patterns instead of scaling patterns.

Getting back to SAFe®, if we support the Cynefin Framework, for complexity should we not use emergent practice, instead of best practice? The big picture seems to demonstrate how complexity can be handled with good practice and best practice, slicing the elephant so to speak.  One might say “well one can pick and choose what’s right for the context”. For me, that could be even worse, the slippery slope towards nothing at all changing. Perhaps emergence comes from the show & tells and retrospectives, I don’t know. Because of the use of the word “commitment” over “forecast”, it just feels to me like everything is moving forward regardless using only a slight tuning of what we did last iteration/train.

The attributes that initially put me off SAFe® were as follows:

• It preserves the current order, current roles stay, albeit re-badged
• Agility is the meat in the sandwich, “smushing” the variable scope fixed quality approach from Lean/agility. I don’t buy that Release Train Engineers, re-badged programme managers if I understand correctly, wouldn’t undermine Product Owners prioritisation and team self-organisation. I don’t like the notion of non-business Release Train Engineers telling business Product Owners what to do; it’s like the tail wagging the dog. 
• Higher motivation for Scrum teams is likely to be more about getting on the train, than having combined potentially shippable increments (PSIs) from their 2-week-sprints 
• While I like the Architecture Owner Role of the Disciplined Agile 2.0, the idea of an architectural runway (to my mind) is an excuse to have an overly technically driven delivery, usually the starting point for a WaterScrumFall, disempowering Product Owners
• No guidance is provided like in Nexus, the exoskeleton of Scrum, for how Scrum and Kanban teams integrate their work; the Agile teams do some and the System team does some and striking the balance is up for grabs. Indeed combined continuous integration is considered as an option to way up if the transaction cost is high. It’s difficult to price the benefit of early integration, so could that perceived transaction cost might be an out?

However, given so many organisations are training their people in agility and don’t even have a transformation to support it, at least SAFe® gives them some scaffolding to work with, an enabling constraint in effect. 

I have a problem with Scrum teams using SAFe®.  To be fair, SAFe® does encourage continuous integration and continuous delivery and a potentially shippable increment every sprint. SAFe® has team demos, system demos, and solution demos which demo the integrated work of all the teams on a train/value stream. SAFe® neither promotes feature teams like LeSS nor integration teams like Nexus+. So, I struggle to see how combined potentially shippable increments happen. I’m curious how often combined potentially shippable increments happen every sprint. I think the System Team could be very busy preparing DevOps infrastructure, and supporting for go lives before and after.

My view is that SAFe® with Kanban at a team level is workable. After all, Kanban doesn’t necessarily strive for PSIs every learning time-box; instead, it has cadences which are decoupled from delivery, solving my perception of a 2-week-sprint with (usually testing) “carry over” on 8-10 week release trains. Sure, we can deliver even faster if we use craftsmanship / XP / continuous delivery, but the 2-week-sprint PSI goes away as such with Kanban, at least to my mind. Let’s talk about Scrumban, KanScrum, and KanScrumUp another time (I just made up the last two about a year ago :)).

Given a choice of really bad Scrum / Water Scrum Fall or SAFe®, I’d take SAFE® every time. It’s the only synchronisation pattern (other than the network effect) for Kanban. The “Spotify model” is not a model; it’s what Spotify does, and it’s great. Enterprise Services Planning is more like a body of knowledge on “Kanban for grown-ups” than a synchronisation pattern, at least to my mind. SAFe® supports Kanban at every level. SAFe® is not a “start with what you do now” pattern. SAFe® has a different interpretation on Cost of Delay and forecasting, and SAFe® focuses more on visualisation of the work than limiting work in progress (other than batch replenishment at planning sessions). SAFe® focuses on the full value stream(s), something many folks lose sight of very quickly. I don’t buy the release train “release any time” mantra as it seems like a contradiction in terms. But that would be cool if say the Release Train in that context is just a grouping to help us with the Dunbar number. I’m curious how many SAFe® implementations release “any time”.

But I’d strive for more than SAFe®, for less the SAFe®, if that makes sense. I’d de-scale the organisation. And, that takes courage. I’d transition to a Lean/Agile organisation to take some tension out of the system, the tension between slide deck “fire drills” and “walking the gemba”; aiming for servant leadership / stewardship. I’d aim for job safety over role safety as the LeSS authors say (www.less.works ). I’d use fit for purpose methods and synchronisation patterns. For example, I might use Nexus exoskeleton of Scrum as a stepping stone to LeSS with the Disciplined Agile Architecture Owner role depending on the context. The latest LeSS book looks unkindly at agility transformation roles, that is, if agility transformation is what is meant by “change management” in the new LeSS book. Apparently, one can do LeSS or not, and there is no need for transformation folks like me to get the people ready for it. I’ll discuss more on that in another post. We’re spoiled for options. I might use Kanban, Enterprise Services, or whatever. Every context is different, and I am the Change is almost unrecognisable across contexts; more on that also in another post. 

An ex-boss told me once that it’s better to get people to implement something (apparently) inferior if they can do it really well than pick something (apparently) superior and do it badly. Wise words… SAFe® has lots of support. 

When all is said and done, I support SAFe® in certain contexts. I thank Dean Leffingwell and Scaled Agile® for bringing SAFe® to us, for saving us from ourselves! 

When is SAFe® safe? To my mind, it’s when:

• We want our teams & team members to rock, feel happy, trust each other, feel free to “go with the whole deal of agility”, and continuously improve to rock even more. We want to deliver value early. We want to manage risk early. We want teams to work on the right stuff and have the ability to adapt quickly if we’ve discovered we’re working on the wrong stuff for now. To that end, we care about outcomes and fitness for purpose of the work compared to what’s going on in the market. In a nutshell, we care more about timely outcomes and forecasts over deadlines and commitments. What’s worse than making bad promises? Keeping bad promises. To this end, leaders welcome early bad news over late surprises.
• No other agility transformation effort is active – i.e., a coping mechanism is needed
• We’re aiming for real change over superficial change
• Release frequency of 10-12 weeks is acceptable
• Integration of hardware or other long lead time value items (up to 10 weeks) with shorter lead time value items
• There is zero appetite to de-scale organisation 
• There is zero ambition for a fully Lean/Agile organisation with only Lean/Agile roles like Architecture Owner, Scrum Master, Flow Manager, Product Owner at various levels. 
• Kanban is used at the team level, therefore Kanban is used at all levels. However, Kanban is implemented as per the Essential Kanban Condensed guide.
• Scrum is used at a team level with a mechanism to ensure a combined potentially shippable increment every sprint – could be like a Nexus integration team concept, a feature team concept or something else. I don’t buy that a network effect alone would handle it. Only use Scrum if Product Owner role is not undermined and Scrum Masters aren’t expected to be agile project managers.
• DevOps is fully embraced, and test automation is part of the way we do our work
• Everyone affected by SAFe® receives official SAFe® training – SAFe® is very well documented but mindset change is needed, possibly with in-class training
• Product Owners feel fully empowered – no role is undermining the Product Owner role
• The equivalent of UAT, customer acceptance testing, non-functional testing and any testing needed prior to a production release are done before the production release – we need feedback to be as early as possible, so let’s not fudge the release train
• The best help is hired 
• Release Train Engineers and Value Stream Engineer’s an all other SAFE® management/leadership roles demonstrate David Spann’s “Agile Manager Behaviours”, i.e., RTEs and VSEs are not just rebadged programme/portfolio managers 

One should ask oneself what problem one is trying to solve and not get obsessed by dogma. 

If you can see the flow of value per value stream, and continuous improvement of lead-times (pick the right metrics for the goal), you’re already off to a good start regardless of the approach whether that is the Kanban method, Enterprise Service Planning, Scrum, LeSS, Nexus, SAFe® or whatever. Systems thinking is important. We aim to continuously improve from whatever to something better. 

Just for some entertainment and light relief from this crazy world, I hope that Dean Leffingwell will have a debate with Dave Snowden, if it hasn’t already happened. I want a ring-side-seat for that one:). So much for non-violent communication eh! 🙂 …….

All views are mine. Looking forward to your feedback…