4 Signs That Agile is Declining-The Sequel

It’s been more than two years since I’ve wrote “4 signs that agile is declining”. I gave a talk at Agile Eastern Europe (which hopefully will be up soon) that revisited this topic. I went over  things I see today that help agile lose. Not because it’s bad, but the way it seems from business point of view.

Here’s a summary. And if you’re good, I’ll give you a bonus sign in the end.

We’re moving too fast

Developers know this: technology changes every two months. We’re either on the bleeding edge, or we’re considered old hat. If you asked a business person if that makes sense, he’ll laugh in your face. When you talk about methodology, it’s even worse.

Agile has been around for something like twenty years. In that short (yes, that’s considered short) space, we’ve gone from XP and scrum, to lean and kanban and now to SAFe. We’ve been creating certificates all over the place.1mrhappygoluckyisout-1

So the business person says: Slow down. If you’re changing your mind left and right, why don’t I wait until you relax, choose something that will last for 10 years, then call me back. Because I’m not training my whole organization on scrum this year, and re-training them on kanban in three years.

The funny thing is that even if we don’t have enough experience with our own methods, we have no problem suggesting what we do to our friends. “Yes, you should definitely do stand-up meetings, it will change your life”.

The agile meter

Because if you’re not doing stand-ups you’re not agile.

This kind of stupid is part of agile conversations everywhere. “You’re doing scrum? We moved on to kanban”. People with enough mileage will tell you this is another holy war like they’ve seen before.

And like any holy war, an outsider business person says: Stop acting like little children, and tell me what I should choose!

And this is where the salespeople come in.

The commoditization of agile

“All you need to do is have three roles, five activities and three artifacts, and that will solve all your problems”.

Why  was scrum the one that crossed the chasm? It simplified things, and spoke the business language.

But when you simplify too much, you leave out the most important thing – context.

Everyone with some change management experience under his or her belt will tell you: It’s all about context. Scrum tells you that it’s just a starting point.

But that’s how the salespeople are selling. And after the deal is done, the customer sees what agile exposes best: problems. Usually, we don’t have patience to reap what we sowed, so we deem our implementation a failure.

And we’re not done with just failure. We need to rub it in.

Agile reactionists

It didn’t take long until we’ve started some wars within the agile camp. The craftsmanship  people understood that agile implementation top-down leaves out all the technical practices that make “working software”, so they said to the business people “you’re doing it wrong, we’re going to save you from yourselves”.

Or the new hotness, “No Estimates” where developers, been burnt by being human (not being able to estimate) decided to punish back business people who do not carry a dictionary (estimates are NOT accurate). Instead of working together, and work out a plan, no estimates for you.

Way to build the bridge people.

Doom and Gloom

Immaturity of process and people are going to cause a near term disappointment on the business side.

Until it comes to a tipping point where the business will say: Thanks, but no thanks. Get back to me when you’re ready, We, as an agile community, need to grow up. We need to experience and learn. We need to educate about uncertainty and risks. We need to be transparent and fearless.

Repeat after me:

  • There is no silver bullet. No one way to success
  • This is an ongoing  learning. Failure is both inevitable and necessary.
  • Whatever I’m doing may or may not be successful for someone else.
  • I’m willing to help build the bridge between developers and the business.

And everything will be all right.

PS: According to David Anderson, one of the signs that agile is declining, is that people write posts about agile declining.

He’s got a point…
 

Reference: 4 Signs That Agile is Declining-The Sequel from our JCG partner Gil Zilberfeld at the Geek Out of Water blog.
Related Whitepaper:

The Retrospective Handbook

A FREE guide for agile teams.

Are you running retrospectives regularly? Perhaps you run retrospectives once a week, or fortnightly. Do you feel like you could be getting more out of your retrospectives and fuelling continuous improvement in your teams? You may already find retrospectives valuable, but suspect there are ways of making them better.

Get it Now!  

Leave a Reply


8 − seven =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close