The dark side of agility

From the Modern PM Blog
by
Modern PM is a blog about modern project management in all its facets: classic, agile and hybrid. I will share my thoughts about the developments, trends, problems and challenges we face in our daily routine as project workers — and hopefully some solutions.

About this Blog

RSS

Recent Posts

Is the minimum viable product really the answer to everything?

Thoughts about having an icebox on your Kanban board

Why there is so much talk about Far Eastern philosophy in project management

Kanban Flight Levels

How an impediment backlog can help us to get our issues under control



What agility has to do with (much) efficiency and (often not so much) customer value, and why cookies are not always the right choice.

The dark side of agility

“Come to the dark side. We have cookies.”

First things first: I am seeing today's topic through the eyes of project management. And through that lens agility is a great idea. But what exactly is the great thing about it? Why do many people and organizations embrace "agility"? Because it is different. Another approach to getting things done. A different approach than the way many organizations are using. Because let us be honest. Even today, there is still an incredible number of companies whose leadership firmly believes that C2 - Command, and Control - is the best way to have a productive and thriving business. And if you are part of such an encrusted, sedated structure, an agile approach sounds great. Of course, it does. Daring though, but very tempting. Faster decisions, faster work-done, less time-to-market. Different.
But is different better?

Arguments

I hate to be the naysayer again. But what is the dark side of an agile approach? And let us just ignore the arguments that I am hearing from a certain type of software developer over and over again ("Agility is bad because I've done well without agility for 20 years. That was a great time! We didn't bother about those customers and we spent every night fixing bugs.") - so, quotes, arguments, quotes. But I am sure you all have heard this a couple of times.
A few points that are - in my opinion - rather out of line when it comes to agility (sad to see what a buzzword this has become):

Not every company is manufacturing software

Agile methods have an insanely strong focus on software development. Yes, it is getting better. But whether if it is ASD, Scrum, DSDM, or - God forbid! - SAFe. In their origins, some of these methods were developed by programmers and most definitely had programmers in mind. And even the agile manifesto is still officially called Manifesto for Agile Software Development. And where do we see agile methods introduced in companies? In my observation, in the overwhelming majority of cases, it is the IT department or more specifically software development.

But what happens, when the IT is working and thinking agile, but the remaining 95% of my value chain is not? Chaos at the interfaces. And yes, Kanban can help a lot. But - and now I have to be careful - in my eyes (and the eyes of many others), Kanban is not part of the agile world. It is more Lean Management. Similar matter altogether, but another. Matter altogether. And yes, your magic-agility-coach told you otherwise, I know.

Pussyfooting

Kaizen and a steady improvement in small steps are fine and dandy. But every now and then it just takes a bit of Kaikaku. The big time. And I won't be able to achieve that if I am spending my time thinking in User Stories. Because that is contagious. And even if the strategy on the top level is good - the best strategy won't help me if the visions get shredded beyond recognition on their way to the implementation level. But that is what I am observing in many organizations that switch to agility: a rigid set of rules is replaced by another rigid set of rules. And then all are writing small User Stories and eventually everyone is thinking small. Good as gold. However, I will not experience any movement.

Standstill through prioritization

Agile methods live from constant prioritization. But, if only the currently most important things are implemented - who will take care of the right things? Those who may not be the most important at the current situation and time (and in my little world), but on a larger, more global scale. They fall by the wayside. And that is how I slow down my organization enormously in the long term. And at some point, I arrive back from where I started: Standstill. Standstill through prioritization.

Efficiency is not always the same as customer value

Agility creates teams that are maximally efficient. This pleases management and controlling. Agility thus also creates teams that have completely lost sight of the customer value. And that is also my main criticism of the way agile methods are often interpreted and lived.

But why is the customer value neglected? One word: velocity. At some point, teams only have this number in their heads. The average Story Points done per Sprint. The team's pace. And everything is subordinated to this team's pace. People will not rely on their own gut feeling. How much work I can accomplish as a team in the next few weeks. No, people are calculating. Because the Scrum Guide says so. (And here we are again with rigid systems.) So everyone is drawing down the line on their burn-down chart. How many Story Points have they done today? Rather than talking about what value has been generated for the customer. Instead of talking about how they have supported and advanced their own organization today. And many Scrum Masters participate in this madness, without even questioning it once. Because the Scrum Guide says so. (And yes, I'm just cynical and unfair now, I'm sorry!)

So what does that all mean?

What can I do better when talking about the above points? How can I avoid the negative and reinforce the positive?

The most important thing first. If I want to change my organization, I should consider whether agile project management methods are generally the right ones for the change part (ie the projects). If I am not better off looking from project to project - where am I on the complexity matrix? - and then deciding which approach to choose. Predictive, incremental, iterative, whatever.
And the second most important point for me: those who agilize organizational units are completely wrong in my eyes. What has to be agilized is products and services. Or their production. And here I am talking less about a set of rules, but more about a philosophy, a mental attitude. Since I have to convince people, not just send them. But to whom am I telling this.

All in all, agility is certainly a good thing - as long as I am using it for the right problems. And it's not outdated (even if agile project management methods are much older than the trend would have us believe). But maybe there is no one-size-fits-all when it comes to project management. And so maybe it is time for something new again. This time, not something different, but something better.

Posted on: May 18, 2019 10:14 AM | Permalink

Comments (14)

Please login or join to subscribe to this item
Great post Stephane - You make some very good points !

Rami, thanks for your kind words! I guess I'm in Agile PM for too long, so I've started seeing the not-so-bright sides quite some time ago. But all in all, I'm still convinced that the philosophy resp. the mindset behind the manifesto is great because it is centered around humans and not around processes.

Stephan, let it out :)

One of the biggest frustrations is velocity does not equate to value, though, if the backlog is mature and prioritized properly, then delivered stories in each sprint is delivering value through those stories - but how is that measured? Since story points are relative, and relative from the Dev team perspective, how does one equate that to value delivery. An aspect of SAFe that I like is that the PO team weighs and assigns a value rating to features/stories.

Andrew, I totally agree with you. And you found the one thing in SAFe that is actually working :)
I see more and more organizations, where more than one person is prioritizing the backlog. Mostly PO plus technical lead plus functional lead.

“maybe there is no one-size-fits-all when it comes to project management” is the best description of the issue. The solution depends on so many individual factors and the mistake we make is trying to make teams and delivery methods fit predefined solutions

Sean, thanks for your comment! I'm glad you like it. And yes, I think you are right. The wrong turn is taken at the moment where "a Scrum team" is built. At that very moment, I have a hidebound solution - the opposite of agility.

Hi Stephan, this is a great post and it makes me happy to read so much of a common sense.
Lenka

Lenka, thanks for your kind words! I'd love to have a like button for comments here :)

Whether you are an agilest, traditionalist or a hybrid; you can easily lose focus of what matters for your customer if you assume your framework or approach has you covered. A mindset of “challenging” everything, everywhere, every time is the safest route.

Great post!

George, you are so right! Every project is different. And thanks!

"Because the Scrum Guide says so."

I needed that laugh! Great post.

Dogmatism of frameworks and methods needs to change. Following any set guide to the letter is not really being agile. Break the rules and develop your own when it improves the situation.

Mark, thank you! Glad you enjoyed it. And I agree with you. People spend way too much time in the Shu of Shuhari.

Thank you for sharing.

I don't believe in pure agile, but i know, that if you use agile for some parts - it makes perect results.
But if you try to make agile only - it fails in big part ot tries..
Thats my opinion and my experience.
And yes, agile is much older than some people try to convince us

Mikhail, I agree with you. Agile methods can be really powerful. Especially when it comes to daily business and software development.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty."

- Winston Churchill

ADVERTISEMENT

Sponsors