The Less Safe Dad - Acronyms in Agile

If I said to you I know about less safe dad, the place where your brain would go probably isn’t toward project management. Technically, if I was being completely correct I would say LeSS SAFe DAD. Sort of looks more like a cry for help created from newspaper cuttings than ways of working.

Acronym Overload

However, LeSS, SAFE, and DAD are all Agile frameworks. Moreover, they are used for similar purposes:

• LeSS http://less.works/ - Large-Scale Scrum (I have a problem with acronyms containing a letter from the middle of a word but that’s probably a different blog)

• SAFe http://www.scaledagileframework.com/ - Scaled Agile Framework

• DAD http://www.disciplinedagiledelivery.com/ - Disciplined Agile Delivery

So different names, different diagrams, but a relatively similar concept. Sell a framework to a large-scale company that will, in theory, allow them to introduce Agile into complex organisations.

However, theory and practice are worlds apart, and nowhere is this truer than an organisation with tens of thousands of employees across many different departments and locations.

In the decade I have spent using various Agile ways of working, I’ve met many people from large companies that are undergoing an “agile transformation”. However, it always seems to be something that is half way done. I don’t think I’ve ever encountered someone from a large, complex organisation that would consider themselves transformed into a truly Agile company.

I feel like a lot of that comes from the overwhelming number of frameworks and models that have appeared in the Agile space. When I first started using Agile, Scrum and XP were basically the only names dropped by aspiring coaches trying to help us work smarter. Now, there seems to be a new acronym every week to describe something I’ve been doing a long time, but that hasn’t yet been adequately monetised. Deloitte’s “Agile Landscape” paints a really great picture of this problem:

Looking at that, you could continuously “transform” your organisation right up to the point where someone decides that the specific framework that you are using to transform isn’t quite right. Organisations that have got on just fine with SAFe suddenly themselves trundling off to a DAD training course. Those invested in Scrum (or perhaps LeSS) could end up being drawn into a Mikado method refresher to enhance their capabilities. The permutations are seemingly endless.

So What’s the Problem?

Many would argue that the above looks like progress. We’re expanding the world of Agile! We’re building frameworks that make Agile work EVERYWHERE! To me, the problem with this thinking has multiple angles:

We’ve started flogging Agile As A Service

It’s probably a fairly cynical way of looking at things, but as more and more frameworks get added they feel less like a valuable contribution and more like a way to make money. If you’re finding less enthusiasm for LeSS, hey, you can just pivot and start selling DAD! People stopped doing the SAFety dance? Maybe you could try scaling Crystal! I actually had never heard of Crystal until I had a proper dig into the Deloitte diagram but it’s there. It also has a step called “walking skeleton” which has intrigued me.

We’ve forgotten why we do this in the first place

When you go back to the core of Agile, it’s a simple set of four principles. You don’t need a replication of the London Underground tube map to understand it. For me, the clue is in the name. "Agile framework" has always sounded like a bit of an oxymoron to me, because if you adhere too strictly to any one framework, you’ve ceased to be Agile. Every one of the frameworks listed above has at least one step in it that could be perfect for you. So use it. Want to do Scrum but hate story points? Ditch them and try Little’s Law instead. Think you could have a great design sprint while using Cynefin for UX? Dig out your Welsh pronunciation book and have at it. Agile is what you make it, not what people tell you it should be.

Agile doesn’t - and shouldn’t - work everywhere

Sorry. There are some really interesting untapped avenues where Agile could make huge inroads, and in no way have we reached a saturation point with Agile adoption in various industries. However, there are always going to be some places where Agile doesn’t work. And we shouldn’t try to squeeze it to fit just because we feel like it should. And one day, we’re going to framework ourselves into a corner that makes working Agile less desirable, not more.

Where do we go from here?

Agile, and the community around it, feels like it has reached a tipping point in the last year or so. From #NoEstimates to #NoProjects, movements and arguments abound about the “right” way to do Agile. We run the risk of alienating new users by presenting a seemingly endless list of rules, and the insistence that our pet theory is somehow more right than all the others.

I’ve definitely been guilty of the above myself. I love working with Kanban, and I think it’s a really productive way of doing things. However, I’ve been experimenting with introducing (and removing) elements from other frameworks to increase our efficiency even further. As much as I love the theory, in reality, I have to put the practice first. If something about my theories isn't working for the client, those are what I need to change.

There is also a myth that in order to scale Agile, you need a framework. This has always felt like trying to retrofit Agile so that it looks more like what large companies are used to. Transformation through the medium of illusion. While it is most definitely harder to introduce Agile in a raw form into a huge company, the rewards can be much bigger. I’ve seen teams achieve remarkable things in multinational organisations by fighting for picking the right ways of working at the right time.

We need to stop pitting ourselves against one another. The LeSS person and the SAFe person both want the same thing, but by focusing on why our framework is the best one, we forget why we do Agile in the first place. Because we want to get stuff done. So let’s just do it.

Want to work somewhere where you have the autonomy to make excellent process decisions, rather than being backed into a framework corner? We're looking for experienced Agile Project Managers!