Scale to Safety

Every now and then there’s a new buzz on the block, and everyone’s, or at least most of us, talk about the new buzz. It just seems the right thing to do.

Well, the fairly new buzz is SAFe and his best mate DAD, and they are eager to help you scale your enterprise agile implementation. They’ve got all kinds of graphics and diagrams to help you achieve that goal, which you can delve into in courses and certifications, so your organization becomes a master in scaling agile.

OK, so you’ve done the course and you now have your certification. Now what? Can you scale? What’s your next move?

SAFe at heart, not in practice

Sadly, life is not as simple. Organizations are not simple either. And not so surprisingly, the bigger the organization, the more complex and unique it becomes. You don’t need a certification of any kind to understand that.

In an analogy, it is like working with MS-Project to become proficient in program or project management. As we all know, this is just not enough. Not that MS-Project is all bad – working with Gantt charts is neither good nor bad (although using a 19th century invention to manage 21st century projects is questionable). The problem begins when MS-Project or SAFe or even Scrum becomes a goal in its own write. As I’ve written before, a practice designed to help things out becomes the main occupation of many, leading to increased waste of time by many others.

Instead, what you want is to gradually adapt to a mindset that advocates focus on results, simplicity, autonomy, flexibility – the core values that no single epic, feature or story can ever resolve.

Interestingly, it seems that the intentions of the originator of SAFe, Dean Leffingwell, are doing just that: To have a scaled Agile manifesto with values and principles. To have a Scrum-like framework for the enterprise level. Lyssa Adkins, a highly esteemed Agile thought leader went to hear about it “from the horses mouth”, as the saying goes, and she writes in her recent blog-post that, despite her skeptical original thoughts, that it does just that.

Alas, maybe hearing it from Leffingwell is not the same as receiving the message from others. Ron Jefferies, the founding father of eXtreme Programming (XP) and an original signatory of the Agile Manifesto, thinks SAFe is not Agile, having completed the course and certification by two highly-esteemed Agile thought leaders. He thinks that “[a]s someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.”
Ken Schwaber, co-inventor of Scrum and also a signatory of the Agile Manifesto, thinks SAFe is unsafe at any speed. Schwaber states “[k]eep the values, keep the principles, think for yourself.  A core premise of agile is that the people doing the work are the people who can best figure out how to do it.”

The harsh reality is that overly prescribed recipes for scaling agile come from good causes, but bring mediocrity, submissiveness, obedience – the exact mindset that Leffingwell he wants to avoid. I should know – I’ve been a member of an organization that invented a very similar framework that suffocated innovation and increased dissatisfaction. It made me want to leave, which I ultimately did.

An Alternative to Scaling

The alternative is to appreciate that SAFe and the likes focus on one aspect of scaling Agile – scaling up. They neglect that other scaling direction – scaling wide. Not that SAFe is all bad, it is just far too little to enable scaling. By the same token that the MS – Project is not all bad – it is just hardly enough to manage projects, and, when relied upon as the main tool for managing projects, it creates more damage than good.

The things SAFe neglects are, for example, the natural flow of knowledge between individuals and teams; the ability of the organization to organically change shape (structure) to adapt to changing realities, with no dependency on management; the ability to collect requirements and to get them from the customers’ field to the engineering shop-floor with the smallest opportunity for distortion.

If these statements are new to you or seem impossible to attain, then you should familiarize yourself more with Agile experts such as Johanna Rothman and Dave Snowden and Gojko Adjic and Henrik Kniberg and others. They are all masters of “scaling agile”, just that normally they don’t call it that. Instead, they are looking at an Agile implementation as a proliferation of a system as it does in nature. It expands, it doesn’t scale (unless it’s a school of fish LOL).

You should grab every opportunity to learn from such experts. Why? Because being happy and productive is not about managing the scale in a better way. Instead, it is about spreading the word in a way that makes success contagious.

Just the same way that ants do not use MS-Project to scale their anthill up. No, they expand it according to the changing needs of their ant colony.