The Scrum story (Scrumageddon) directly from your workplace
When I opened my LinkedIn this morning, one of my connections posted this funny one-liner about Scrum practices:
The JIRA backlog is like a black hole — stories go in, but nothing ever comes out.
I couldn’t help but chuckle as I thought about a recent fun conversation with one of my old colleagues (James) about how his team is approaching Scrum.
Who is James?
I have known James for more than a decade now. We worked together in one of my previous companies for some time, and I respect him for being an Agile purist. I know there aren’t many left in the market these days. Over the years, we remained in touch via social media platforms like LinkedIn and Twitter (now X).
Coincidentally, I again met him in person in London during a product conference, and we decided to have lunch together. That’s when he narrated this funny Scrum adoption story to me.
I have changed the company’s and other players’ names to keep them confidential. I’ve also changed the narrative style to be more conversation-based to keep the fun quotient alive.
I am telling you this story from James’s viewpoint and taking a few creative liberties to keep it engaging.
As an Agile Coach, I (James) thought I had seen every Scrum anti-pattern imaginable when I joined MyDevTech Inc., a company known for its SaaS-based customer discovery platform. But this team — oh, this team — was about to redefine my understanding of chaos.
Day 1: The daily stand-up that never stood
“Welcome, James! Excited to have you on board,” said Sarah, the Product Owner, as she introduced me to the team. “Let’s jump right in — our daily stand-up starts in a few minutes.”
A good start, I thought, until I entered the meeting room.
Instead of standing in a circle, people were lounging in chairs, sipping coffee, and checking emails. The meeting dragged on for a good 45 minutes, with each person giving long-winded updates that sounded more like therapy sessions than status updates.
Bob, the back-end engineer, was deep into a monologue about his neighbour’s loud dog before Sarah, the Product Owner, finally interrupted.
“We really need to keep this short, guys! Let’s try to stick to the three questions next time.”
Bob nodded.
“Got it. But before we move on, I just want to mention…”
Sprint Planning: Where everything is priority #1
The next day, I attended sprint planning. The team had a product backlog of more than 200 items, and every single one had a “high priority” label.
Sarah started: “So, let’s just take the first 50 items in the backlog and put it in the sprint.”
“50 items?” I asked, trying to mask my horror.
“Yes! The stakeholders want these done ASAP, so let’s commit. We can just work harder”.
The team reluctantly nodded. Steve, the Scrum Master, pitched in, “Commitment is key in Agile!” He sounded proud.
I hesitated, then carefully asked, “Didn’t we just spend 45 minutes in stand-up yesterday discussing how overworked the team is?”
“Yes, but we’ll figure it out as we go,” Sarah replied cheerfully.
I continued, “Don’t we have product backlog refinements? We can discuss backlog items, add details, decide priorities, manage dependencies, etc.”
As I was fearing, I didn’t get a response.
The everlasting sprint
At the end of the two-week sprint, I expected a sprint review and retrospective. Instead, I was in an emergency meeting called “Sprint Extension Planning.”
“We didn’t finish our sprint goals,” Sarah admitted. “So let’s just extend this sprint for another two weeks.”
I nearly choked on my coffee. “You’re… extending the sprint?”
“Yeah, it’s easier than moving the unfinished work to the next sprint. Plus, calling it a new sprint feels like we failed.”
I glanced around the room, waiting for someone to protest. Nothing.
So much for timeboxing.
Retrospective: Blame Fest edition
When we finally had a retrospective, it was more of a “find the guilty person” session than a reflection on improvement.
“I think the front-end team is too slow,” declared Bob. “We were blocked for three days!”
Linda, the front-end engineer, shot back, “Maybe if the back-end APIs weren’t changing every two hours, we’d be faster.”
Steve, the Scrum Master, nodded sagely. “I think we’ve identified a key issue: everyone needs to work harder as we have delivery deadlines to meet.”
Nobody took notes. Nobody proposed solutions. No actions. The only takeaway was that “we should all try harder.”
I was about to pull my hair out of my head.
Scrum Master or Taskmaster?
Steve had an interesting interpretation of the Scrum Master role. Instead of serving the team, he acted more like a project manager from the 90s.
“Where are your updates on JIRA?” he demanded. “I need to report to leadership.”
“We’re figuring out the best approach,” said Mark, a developer. “We’ll update it once we finalize the details.”
Steve frowned. “Scrum is about transparency! If it’s not in Jira, it doesn’t exist.”
I noticed Mark sighed and started typing random status updates into Jira. I later saw a task titled “Waiting for divine intervention” assigned to him.
I still don’t know why.
The Definition of Done (or lack thereof)
By week four, I noticed a strange pattern. The team marked tasks as “Done,” but when I checked, many weren’t actually complete.
“We finished the coding,” said Bob. “That’s done, right?”
“But it’s not tested,” I pointed out.
“Oh, that’s QA’s problem,” he shrugged.
Rita, the QA, it turned out, was one overworked tester drowning under a backlog of “done” tasks.
“Could we define ‘Done’ to include testing and deployment?” I suggested.
Steve shook his head. “That sounds like a process change, and we don’t have time for that.”
Scrum theater for executives
Every two weeks, the team put on a grand performance for leadership, showcasing completed features that weren’t actually complete.
“And here’s our new customer journey, CLI!” Linda announced during a demo.
“Looks great!” said the CTO. “Can I try it out?”
Linda winced. “Well, it’s not live yet. We still have a few bugs.”
“Okay, so when will it be ready?”
Steve jumped in. “Soon. Next sprint, for sure!”
Spoiler alert: It wasn’t.
Steve then showcased the JIRA team Velocity report and bragged about how the team commitment has been more than 90% during the last 3 months.
Intervention time
James took a sip of the coffee and continued with his story.
After a month, I couldn’t take it anymore. I gathered the team.
“Guys, I think we need to rethink how we’re doing Scrum.”
Blank stares.
“First, let’s actually timebox sprints and stop extending them. Second, we need a clear definition of ‘Done.’ Third, retrospectives should focus on solutions, not blame games. And please start having periodic refinement sessions. Let’s not commit to everything in the backlog.”
Silence. Then Steve said, “I think what you’re proposing is a bit extreme.”
Bob nodded. “Yeah, this feels like a big shift. Can we just do a small retrospective on whether we want to change?”
Sarah added, “We’re already Agile, so why fix what’s not broken?”
I resisted the urge to laugh.
Conclusion: The never-ending Agile journey
Over time, I managed to introduce small changes — timeboxed stand-ups, realistic sprint planning, and an actual definition of Done. But some habits die hard.
Once, I overheard Sarah say, “We should do a retrospective on whether our retrospectives are useful.” Steve nodded, “Let’s backlog that.”
I sighed. Some things never change.
The team still had “Sprint Extensions” (though they called them “Rolling Sprints” now), and Steve still treated JIRA like a sacred text. But hey, progress is progress.
Mark passed by as I left the office one evening and whispered, “Thanks, man. At least we don’t spend an hour in stand-up anymore.”
Small wins. I’d take them.
Ultimately, Scrum is about continuous improvement — even when it feels like herding cats.
The paradox of Agile: even when it’s done completely wrong, teams still believe they’re being Agile. And maybe, just maybe, recognizing the dysfunction is the first step to fixing it.
I hope you liked James’s story. I can’t tell how much of it is real or fiction, but who cares?
I shared it because this is a typical pattern in every organisation. It may be more or less so, but Scrum anti-patterns exist everywhere.
Leave a Reply