This is not a rant, but rather a learning, there are thousands of ways to do something wrong, very few to do it right. I must say, I have been a part of few that went wrong for sure and hence this blog.
In the early and dreamy years of my career, I was once part of a project team that decided to “go Agile” because, hey, it’s the new millennium, and you know, it’s trendy, and everyone’s doing it. But did we actually know what that meant? Absolutely not. The client had probably read somewhere in a magazine (yes, there used to be such things as magazines and we used to subscribe to them and read them – physical – paper based!!) about Agile … yeah, I am sure it was just some magazine, not a book, or a series of articles … and declared that we would now be running everything in “sprints”.
So, there we were, a group of 11 people, gathered for our first-ever stand-up meeting. And by “stand-up,” I mean we stood awkwardly in a circle while the manager read off a list of “tasks” we had no context for. Saying things like, “We’ll complete these 50 tasks by Friday,” as if they were simple grocery shopping lists. I asked, “Um, shouldn’t we be discussing priorities?” But apparently, in our new Agile framework, “everything” was a priority. Red flag #1.
Then came the kicker: “daily” stand-up meetings at 8 a.m. sharp. Now, as much as I love dragging myself out of bed at an ungodly hour, discussing the same tasks every day quickly turned into a “how good are you at pretending you’re busy” competition. I remember once saying, “I’m still working on the same task from yesterday because, you know, code doesn’t write itself overnight…” My sarcasm was not appreciated. Note to self … It never works!!
But the real fun started in Sprint 3, when our manager decided that Agile meant we didn’t need requirements… at all. “Agile is flexible!” was a declaration. Flexible apparently meant, “Let’s start building things without knowing what they are.” So, we built a Frankenstein of a product, a mismatched collection of features no one asked for, didn’t test, and ultimately had to “scrap” entirely. We were so “Agile” that we never finished anything.
At the end of it all, we didn’t even bother having a retrospective. I guess reflecting on how we went from zero to flaming disaster wasn’t in the “Agile” spirit.
Later in life, I was a part of large Scrums and Scrum of Scrums and got some training. Met a few stalwarts who could do this the right way. In the recent times, I again saw a circus with 200+ development resources working in an “Agile” environment going nowhere. The client has now slapped the consulting company with a fine due to the delays – No I am not going to name the project and the company. If you know – you know.
So while digging deep about the statistics of how effective Agile is in real world scenarios … came across some cold, hard facts to statistically back up my chaotic Agile anecdote. Turns out, what we experienced isn’t all that uncommon in the wild world of Agile gone wrong.
First up, the “daily stand-ups”. According to the “State of Agile Report 2020”, 87% of teams use daily stand-ups as a core Agile practice, but here’s the kicker: a survey by “Mountain Goat Software” showed that around 30% of stand-ups drag on longer than they should, wasting time instead of improving efficiency. So yeah, our “8 a.m. meetings that devolved into status updates nobody cared about”? Pretty textbook case of what not to do.
Now, about our brilliant “everything’s a priority” approach. Agile prioritization is supposed to focus on “value delivery”, not overwhelming your team with a task dump. According to a report by “Wrike”, 55% of workers said unclear priorities cause their biggest stress. So when I asked if we could actually, you know, prioritize things, I wasn’t just being difficult; I was trying to save us from drowning in a sea of tasks”.
And the whole “requirements? Who needs ’em?” vibe? That’s a classic misinterpretation. Agile does emphasize flexibility, but a large amount of Agile projects fail due to “unclear objectives” and “miscommunication of requirements.” In other words, Agile doesn’t mean “no plan” … it means adapting “a plan” when necessary. We didn’t even have a rough draft of a plan.
Here’s a quote from “Jeff Sutherland”, one of the creators of Scrum: “If you are doing it wrong, Scrum will show you right away.” Yeah, well, “we didn’t need Scrum to show us that our ship was sinking … we could hear the gurgling”. By the time we were halfway through Sprint 3, we weren’t Agile, we were flailing around in chaos with “work” that had no direction, no testing, and no value.
So it wasn’t just us … we were part of a much larger pattern of teams trying to adopt Agile because it sounded cool, only to faceplant spectacularly due to a lack of understanding.
In the end, I believe that without structure, a clear definition of what you’re actually trying to accomplish, and a sane approach to meetings, Agile can go from a productivity booster to a flaming disaster faster than you can say “sprint retrospective.” Beware!!
