Benefits of SAFe Agilist Certification
In today's rapidly changing business environment, it is essential for organizations to be agile and...
Image on slide presented over my head in this photograph is from the
Reinventing Organizations book by Frederic Laloux
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:
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:
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...
John Coleman has been knocking around with agility since 2004, starting with a mission critical piece of work back then against advice and taking on ever more scary work since then :). A speaker, consultant, coach and trainer on all sorts of agility.
In today's rapidly changing business environment, it is essential for organizations to be agile and...
The SAFe Release Train Engineer (RTE) and SAFe Scrum Master (SSM)...
Leave a Comment