Does Your Agile Lead to Agility?
You’re not Agile.
That isn’t Agile.
That isn’t how you do Scrum.
That’s not SAFe.
When did we decide to canonize the gospels according to Cockburn, Schwaber, Sutherland, and Leffingwell?
What ever happened to: “we are uncovering better ways of developing software by doing it and helping others to do it?”
When did we begin putting Agile over Agility?
Let’s be real. Most companies can’t actually do Agile. They can’t do Agile at scale. They aren’t built for it. Faced with that reality, you have two choices—change Agile, or change the company.
Most companies will benefit from better organizational alignment.
Most will benefit from breaking down dependencies.
Most will benefit from putting more energy into getting specific about what they want to build.
Most will benefit from a more adaptive governance model.
Most companies will benefit from having a better understanding of capacity against demand.
Most companies will benefit from working in smaller batches and releasing to market more frequently.
Most will benefit from getting faster feedback from their customers.
Most will benefit from better technical practices, software craftsmanship, and modern delivery techniques.
How many will benefit from doing a daily standup?
From a retrospective?
From having a Scrummaster?
From doing big room planning?
They’ll only benefit to the extent that those practices lead to the stuff in the first part of the list.
So, how do you know if your process, or your framework, or your methodology is delivering the benefit?
Will the people doing the work, really refactor the system?
Do they really know what adaptive governance looks like?
Are they educated on modern delivery practices?
Scrum only shows you your problems. It’s up to you to fix them. Does your team know what to fix? How to fix it? How to enlist support? How to create a business case? How to get your executives engaged?
If not, Scrum won’t fix anything.
I personally don’t care if what I am doing is Agile. I care if it leads to Agility. It’s time we start testing our hypothesis that doing Scrum leads to Agility. Lot’s of time it doesn’t.
For me it’s teams, backlogs, and working tested software. Break dependencies. Remove impediments. Then, do whatever process works for your group. It won’t matter if you get the process right, if you can’t fix the ecosystem.
Most companies don’t need Scrum, or SAFe, or LeSS, or DaD.
They need team based iterative and incremental delivery. An ecosystem that maximizes encapsulation. Minimizes the need for orchestration. A mechanism for balancing capacity against demand. Lightweight governance to make economic tradeoffs in the face of constrained resources. To ensure we are making decisions in small batches and getting feedback from our customers as we build the product.
And, sure—I might use some Scrum, some Kanban, some SAFe, and some LeSS. Maybe even some DaD if it had a less silly name, but none of that stuff would be the point.
Agile is only Agile if it leads to Agility.
Do you have agility?
Comments (4)
Robert Pieper
Let’s start with I agree with many of your points. Being an agile product development organization is way more important than following some set of rules. I’m not big into following rules. However, there are many, many people out there that want to know how to do basic things to improve. They need some sort of basic steps to follow. When first learning Karate, one must learn basic form, punches. blocks, before they’ll be able to use them in combination to spar a real opponent. We know what the goal is, but progress must be taken in steps toward proficiency. This is where agile frameworks and methodologies come in. They were never intended to be a religion, or a strict set of rules. They’re meant to give novices a path forward. There are many Scrum bashers out there, but bashing isn’t necessary. Scrum was designed to solve all the problems you stated. Scrum is a framework, and I see it a bit like a tool. You don’t make fun of a screwdriver and call it ineffective if there’s a large population using it to pound nails. Scrum used incorrectly will yield similar pains and frustrations. My 2 cents. See you on the public speaking circuit!
Erik Ågren
Interesting post! I can really identify myself and my agile trip so far (since 2005) in the same insights as you describe. But as commented by Robert I can also see the need of frameworks at some phases. Depending on where you are on your agile learning trip, Shu, Ha or Ri, you need a package or a framework/methods to get started. But it’s very important to not get stucked in them to reach agility. One of the important things with agility is continuous improvement, that’s what you need to do, learn and improve all the time, so that you can move from Shu to Ha and later to Ri, and with new insights tweak everything in the organization towards agility, If that’s what the organization really wants, a lot of times they just implement Scrum because you should do, then you don’t move any further. There is so much to change in an organization to really reach agility, and the whole organization need to see this and want to move. All the management really have to want this! And that’s normally the most tricky part!
/Erik
Usman Ghani Thakur
Simply an excellent post that clears a lot of misconceptions around Agile and Scrum.
Mary Laniyan
Great write up and comments for a balanced view.
The goal is simply always a never ending journey to high performance for me. What’s key, regardless of Framework is that they have been empowered to continuously find their path to high performance (Agility).