DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DataOps
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • Techstrong.tv Podcast
    • Techstrong.tv Video Podcast
    • Techstrong.tv - Twitch
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Content
    • Sponsored Content
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Techstrong TV
    • Techstrong.tv Podcast
    • Techstrong.tv Video Podcast
    • Techstrong.tv - Twitch
  • Media Kit
  • About
  • Sponsor
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DataOps
  • DevSecOps
  • DevOps Onramp
  • Platform Engineering
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps
    • ROELBOB

Home » News » Best of 2022: Agile/Scrum is a Failure – Here’s Why

Best of 2022: Agile/Scrum is a Failure – Here’s Why

By: Richi Jennings on January 3, 2023 Leave a Comment

As we close out 2022, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

Welcome to The Long View—where we peruse the news and strip it to the essentials. Let’s work out what really matters.

TechStrong Con 2023Sponsorships Available

This week, something a bit different: I’m devoting my entire column to Agile and Scrum. They’re increasingly getting a bad reputation, being associated with the worst aspects of toxic workplace culture: Sexism, racism, burnout, micromanagement.

Analysis: Bad workers blame their tools

Pack up your Post-Its? Skip your Stories? As always, the truth is more nuanced: Agile methods aren’t always the best tools for the job. And when they are, Agile/Scrum require strong, skilled leadership.

What’s the story? Let’s start with Ass. Prof. Miriam Posner’s recent critique—“Agile and the Long Crisis of Software”:

“Exercises in surveillance”
There are distinct limits to the kinds of creativity workers feel authorized to exercise under Agile. … Developers often don’t get to weigh in on the bigger questions. [And] those bigger questions have taken on greater importance and urgency.
…
Agile might have played a role in creating a work culture that is increasingly revealed to be toxic for women, people of color, and members of gender minority groups. … The authors of the Agile Manifesto were … white men who [had] not spent much time in workplaces where they composed the minority. … Eliminating bureaucracy, hierarchy, and documentation feels great, until you’re the person who needs rules for protection.
…
The Agile Manifesto paints an alluring picture. … The problem is, it’s almost always implemented in workplaces devoted to the bottom line, not to workers’ well-being, [such] as when a project manager is caught between a promise to a client and the developers’ own priorities. … Moreover, daily standups … have become, for some workers, exercises in surveillance [with] pressure for every worker to justify their worth.

All of which generated strong opinions, such as this from Xophmeister:

“Building complex software is a social problem”
This is a great summary about how I feel about “Agile”: It’s patronising and anxiety inducing. The degree of which is a function of the technical and social abilities of … the PM, Scrum Master, whatever. … Leaders with strong technical chops and high emotional intelligence exist, but are rare.
…
Similarly, this is why I don’t believe that a fully egalitarian group of engineers would work, either: … Inevitably, a de facto leader will emerge. In my experience, often the loudest, rather than the most effective. Building complex software is a social problem more than a technical one.

And this, by Kokuyo:

“Train wreck”
I am quitting my current job as a private cloud engineer for a cloud provider because they thought it was a good idea to make us work “Agile.” Sure, we are only plannable for 40-60% of our workweek but the problem is … planning even 40% is quite hard when daily business interrupts just about any plan you have.
…
[It’s] led to three burnouts in a team of about eight … two people quitting and two more to come. … I stand there watching the train wreck happening and nobody in management doing anything about it.

Not to mention this, via u/be-sc:

“Went from being agile to implementing Agile”
A company I know used to work closely with its customers: … So it wasn’t a big deal to start out with flawed requirements, because they could iterate quickly towards a workable solution. Overall it was a pretty agile way of working—although nobody thought of it like that, it was just the natural thing to do.
…
Then the world changed and things were introduced in the name of becoming Agile and practicing continuous improvement. Think of stuff like SAFe or SPICE. And SCRUM on top of it, of course. As a result, those quick efficient iterations aren’t officially allowed any more. Everything needs to be planned and documented and tracked and reviewed and approved and documented again. Meetings need to be held on all of that, of course. And, oh, this only looks like waterfall, but it totally isn’t.
…
The company went from being agile to implementing Agile—and lost its agility.

Ah yes, Waterfall by any other name. Or, as Jeremy Duvall puts it, “Scrumfall”:

“Chaos, crappy code, cost overruns”
The Church of Agile is being corrupted from within by institutional forces that [can’t] adapt to the radical humanity [of] collaborative, self-organizing, cross-functional teams. … Agile wasn’t supposed to be this way.
…
Agile is supposed to be centered on people, not processes. … But many businesses instead prioritize controlling their commodity human resources. … Companies have dressed it up in Scrum’s clothing, claiming Agile ideology while reasserting Waterfall’s hierarchical micromanagement. … Properly implemented Scrum or Kanban [should] lead to the desired outcome within finite time and budget.
…
Stories as mini-Waterfalls [treat] the engineer as a cog in their employer’s machine … with no understanding of the craft, creativity, and critical thinking required to solve such complex problems. … Scrumfall relies, in other words, on the product team … providing a complete and perfect specification before development begins. And it relies on the development team … planning out a complete and perfect implementation before a single line of code is written.
…
The invading Waterfall taskmasters hidden in Scrum’s Trojan Horse absolutely hate uncertainty. However, uncertainty is not a bug but a feature of Agile. [But] these chains of mini Waterfalls create chaos, crappy code, and, ironically, cost overruns and missed deadlines.

But beware of zealotry. Heed the wise words of cestith:

“Anything larger than a developer can do in two weeks is infeasible”
One of the problems people are having is that so much is said against Waterfall instead of just in favor of Agile. … People emphasize that everything to do with Waterfall is bad, and generalize from large, detailed, inflexible architecture with no feedback loops being bad. [This is] repeated by people trained to be Scrum Masters or some other management or administrative role who are not developers themselves.
…
I’ve been told that gating one story behind another is waterfall. I’ve been told that having a design story is waterfall. I’ve been told that architecture documents that are eligible to be revised … but created before all the code is in place are waterfall.
…
Taken to heart [it] means that anything larger than a developer can do in two weeks is infeasible. This often happens when the team building the software is not considered [as] stakeholders.

Whatever happened to “people over process”? Slicker gets real:

“It just doesn't work that way”
Ethics were never a part of software development methods. Those are business decisions. It’s not Agile’s fault or Waterfall’s fault. A hammer is a hammer: You can drive a nail into wood or clobber somebody.
…
As far as giving engineers autonomy, I do see enormous largely unrecognized value in that. Boeing, for example, made great products until the management style was changed to a top-down authoritarian model. … Obviously quality, productivity, and innovation all suffer horrendously. … And I have seen this pattern in company after company.
…
Engineers need latitude to solve problems. Their work is nothing like a production line in a factory. It just doesn’t work that way.

As in other walks of life, there’s no single answer—and nuance is essential. Here’s u/Sammy81:

“You have to plan the whole project”
It comes down to: What are you developing? Some products are well suited to Agile and others aren’t. “Pure” agile is best for a commercial product. … You have a feature set that you prioritize and you get through as much as you can before you run out of time, call it done and try to sell it.
…
When you have a customer who has a list of requirements they insist on, … you can’t just do … sprints and see how far you get. … You have to plan the whole project, resulting in Agilefall.

Meanwhile, I think we can all agree it’s the product manager’s fault. Amirite, spaetzleesser?

I have never seen one that could really guide a project from start to finish. They either don’t understand the tech sufficiently, or they don’t understand the business case, or they aren’t engaged enough.
…
[Or,] once a product manager has enough experience to understand the business and the tech, they get promoted and you have to deal with a newbie.

The Moral of the Story:
The fault is not in our stars—but in ourselves


You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or [email protected].

Image: Brad West (via Unsplash; leveled and cropped)

Recent Posts By Richi Jennings
  • Microsoft Outage Outrage: Was it BGP or DNS?
  • 8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs
  • FAA Ground Stop due to Technical Debt? | Don’t Do DIY Crypto!
More from Richi Jennings
Related Posts
  • Best of 2022: Agile/Scrum is a Failure – Here’s Why
  • The DevOps Culture Cocktail
  • Avoiding Common Executive DevOps Mistakes
    Related Categories
  • Best of 2022
  • Blogs
  • Business of DevOps
  • Continuous Delivery
  • Continuous Testing
  • DataOps
  • DevOps Culture
  • DevOps Practice
  • DevOps Toolbox
  • DevSecOps
  • Editorial Calendar
  • Enterprise DevOps
  • Features
  • Leadership Suite
  • Most Read
  • News
  • NoOps
  • Variable Speed DevOps
    Related Topics
  • agile
  • scrum
  • The fault is not in our stars—but in ourselves
  • The Long View
  • waterfall
Show more
Show less

Filed Under: Best of 2022, Blogs, Business of DevOps, Continuous Delivery, Continuous Testing, DataOps, DevOps Culture, DevOps Practice, DevOps Toolbox, DevSecOps, Editorial Calendar, Enterprise DevOps, Features, Leadership Suite, Most Read, News, NoOps, Variable Speed DevOps Tagged With: agile, scrum, The fault is not in our stars—but in ourselves, The Long View, waterfall

Sponsored Content
Featured eBook
Hybrid Cloud Security 101

Hybrid Cloud Security 101

No matter where you are in your hybrid cloud journey, security is a big concern. Hybrid cloud security vulnerabilities typically take the form of loss of resource oversight and control, including unsanctioned public cloud use, lack of visibility into resources, inadequate change control, poor configuration management, and ineffective access controls ... Read More
« Five Great DevOps Job Opportunities
DevOps Must Embrace Automation in 2023 »

Techstrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Evolution of Transactional Databases
Monday, January 30, 2023 - 3:00 pm EST
Moving Beyond SBOMs to Secure the Software Supply Chain
Tuesday, January 31, 2023 - 11:00 am EST
Achieving Complete Visibility in IT Operations, Analytics, and Security
Wednesday, February 1, 2023 - 11:00 am EST

Latest from DevOps.com

The Strategic Product Backlog: Lead, Follow, Watch and Explore
January 26, 2023 | Chad Sands
Atlassian Extends Automation Framework’s Reach
January 26, 2023 | Mike Vizard
Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off
January 26, 2023 | Bill Doerrfeld
GitLab Strengthens Remote DevOps Management
January 25, 2023 | Mike Vizard
Microsoft Outage Outrage: Was it BGP or DNS?
January 25, 2023 | Richi Jennings

TSTV Podcast

Sponsored Content

The Google Cloud DevOps Awards: Apply Now!

January 10, 2023 | Brenna Washington

Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

December 9, 2022 | Mike Vizard

Why a Low-Code Platform Should Have Pro-Code Capabilities

March 24, 2021 | Andrew Manby

AWS Well-Architected Framework Elevates Agility

December 17, 2020 | JT Giri

Practical Approaches to Long-Term Cloud-Native Security

December 5, 2019 | Chris Tozzi

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays

GET THE TOP STORIES OF THE WEEK

Download Free eBook

The Automated Enterprise
The Automated Enterprise

Most Read on DevOps.com

6 Ways To Empower Developers and Increase Productivity
January 20, 2023 | Bill Doerrfeld
Digital Experience and the Future of Observability
January 20, 2023 | Nik Koutsoukos
What DevOps Needs to Know About ChatGPT
January 24, 2023 | John Willis
Microsoft Outage Outrage: Was it BGP or DNS?
January 25, 2023 | Richi Jennings
Five Great DevOps Job Opportunities
January 23, 2023 | Mike Vizard
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2023 ·Techstrong Group, Inc.All rights reserved.