It’s time to move on from Agile Software Development (It's not working)

I came across a study which found that software engineering projects have a 268% HIGHER failure rate when agile methods are used. And even though it might be biased, we can’t ignore the fact that there are some serious problems with Agile Software Development.

Timeline
00:00 Introduction
01:03 The real issue is not with agile itself
01:22 The amount of meetings
04:23 The Agile Project manager might be the problem
08:55 So what can software engineers do?

[awesomeworld]

It's failing, because agile is being used to micro-manage people

[rccc]

We're at the time when Agile isn't anymore a tool for the team to self-organize but a tool for management to impose micromanagement. On the grand scheme, the gain of productivity was lost. It's just the illusion of measurability that stuck.

[duramirez]

I was "fired" once, because the "PO" said I was slower as a Senior than an Entry level dev. I laugh, cause nothing I ever coded came back bugged, opposed to what the Entry level guy used to make. I only said: Suit your self, if quality is not the priority here, then I agree, I should go. And then I left, smiling. :)

[HansTeijgeler]

Project manager/ product owner here. I am usually getting kicked from above for not religiously dragging the team through a ton of useless meetings and Agile ceremonies. My teams typically love me for that, my bosses don't.

And can someone please explain how a sprint is not simply a two-week waterfall? I still don't get the fuss about what's so great about sprints. Much prefer Kanban and CI/CD...

[anttiviljami]

Head of Engineering running a product team with 35 engineers here. ✋

My advice is: Just skip the damn meetings and focus on building great software.

Show up to demos with great stuff. No one will question you if you consistently deliver high quality work, I promise.

As a smart engineer, you can demonstrate that you’re capable of doing the job better without managers telling you what to work on and keeping you under a microscope.

Here’s how:

Avoid being boxed in as the technical savant who doesn’t know anything other than how to write code.

Ask the right questions. Make sure you understand the user and the business. Do your homework and make sure to talk about customers and why your work is valuable to them.

Take professional pride in your work.

Don’t agree to impossible estimates, or sacrifice quality for the sake of deadlines.

Just deliver high quality working software consistently, and demo it frequently.

The managers and excessive meetings are there because leadership doesn’t trust you. They want someone to keep an eye on you because they believe software engineers can’t make design / product / business decisions themselves.

Prove them wrong and focus on just building something you can be proud of.

[kylek]

I've worked in the role of manager and I have a personal policy -- have the least amount of meetings possible. I swear many middle-management people schedule meetings (in all industries, not just software development) to give the "illusion" that they have a lot of work they need to do, it's corporate theater. How often have you been in a meeting where the relevant portion for you or your team is a 5-minute block somewhere within that 1 hour timesuck? I imagine it's a lot.

[vrrqhll]

There were two things I did to survive “bureaucratic” agile. First, since our overbearing project manager came to the retrospective, we couldn’t voice our real concerns. To combat this, we had a secret retrospective afterwards without the manager so we could talk openly. Second, when it came to estimating, I always estimated as high as possible without breaking out laughing. The manager hated it but had to admit that our customers were happy because we always ended up delivering on time.

[martincronje]

Businesses seems to associate speed and agile with each other. Instead agile works great in a condition where we need to learn a lot. Waterfall works great when we know what works.
My personal opinion is that we should stop taking the frameworks so serious and start to work out how to best deliver business value instead.

[HussainAkbar]

I remember a time when I was with IBM. After the manager laid down new policies for meetings and reporting, a programmer asked: If we do all of this, when do we actually work?

[katchF]

This is such a fantastic video. You've really nailed down one huge problem with modern Agile--people with zero development experience think that the process they manage is itself productivity.

[canadiannomad]

Daily Scrum meetings sucks my will to live, and the only way to complain about it is to a person who's entire job is dependent on "making it work".

[RexTorres]

My problem with agile is that you're given a certain amount of time to finish something. Then your boss comes and tells you to do so many other stuff on top of your actual task and still expects you to finish your actual task in the original time frame.

[TheoWerewolf]

Excellent summation, but I'd like to add a few more issues.

The original problem Agile was designed to solve was for consulting...having a design team meet with the customer, get all the specs, lay out a plan usually waterfall), build the product in camera then hand it to the customer only to discover that it's not what the customer wanted. This happens because real world end uses often don't really know what they want until they see it. So Agile baked that in by having a design team draw up a "big design" plan, then iterating the design on a two week schedule and showing the customer chunks of the final product to get dynamic feedback. THAT works.

Where things went off the rails was the assumption that this works for all development when in fact, it really doesn't. Example: if your Agile team has no customers, or almost as bad, a in-team customer representative who represents the customer but works for the dev company, you're not doing Agile. (Pigs and chickens as we used to say).

Worse, somehow Agile changed from a productivity tool to a productivity MEASURING tool and external managers became "chickens" along with the customers (if you even have any of those), creating a conflict in goal. The managers' goal is to get the product done as fast as possible and make money off the work invested. The customers' goal is to get exactly what they're paying for.
See the problem?

Things like "velocity" weren't part of the original idea either. It was added as a way to check progress and see if there were bottlenecks. Now it becomes a "success" metric on its own merit. I can't tell you how many scrum plans have been rearranged in mid-process just to get velocity numbers up higher. Or how often after a sprint plan is locked, someone in management changes direction and blows the entire plan out the door. (And then complains about OUR velocity...)

Oddly to me, this relates to git or "blame-based source code management" where finding the goats when something goes wrong is more important than just getting the mistake corrected and educating the team. Fear-based development also rarely works.


Agile has a place, but somehow it's turned into a religion and a surprisingly rigid one at that given its actual name.

[TheRealStoryWeaver]

I run very lean Scrumban and it works great. Daily standups are usually 5 minutes. We combine retrospectives and planning into a single meeting every 2 weeks and it is usually done within 30-45 minutes. It works fine as long as the person running it is trying to keep these meetings short and efficient, and the developers themselves are the ones breaking down big tasks into smaller ones, providing their own time estimates, etc.

[javaman]

My employer forced nearly all IT teams to use agile. My team is not developers, we support servers and software on them, along with tuning the configuration of the applications. When we just did business as usual, we were told we were not doing enough Jira stories. So now we have stories for all the little daily things so we can complete more stories. We do less actual work than we did before, but now we have a bunch of meetings and Jira stories to to prove we do work.
The meetings are especially a pain. In 2022 we kept complainng because we were averaing 25 hours per week of meetings. This year we are keeping meetigns more under control, averaging about 15, but it's hard because managment keeps pushing for more meetings and we are constantly pushing back.

[petebrown]

I started coding in the '80s - used to kick out (good) code like crazy, I can't imagine writing a lot of code today - these processes strip all the joy out of the process.

[imagiro]

I remember, when I first heard about agile and asked what it means (about 10 years ago), my conclusion was: I was doing it (developing software in small iterations) my whole developer life anyway.

Now my last project (a European airline) I rage-quitted, and I'm still recovering after almost a year. I already had a burnout (before agile), so I know what it feels like. The description Dee gave fits like a glove.

So my advice: If you have a SM who attended a 2-week-seminar, run as fast as you can.

Otoh I experienced Safe as working almost perfectly when we had an experienced agile coach. She did not buckle and took everyone to task, also, and especially the stake holders. Once they understood that we (the devs) setup the pace, things started to work.

Most important lesson I learned (and anyway suspected right from the start): Do it like evolution does it: Mutate, evaluate, select, repeat. Try things, keep those that work, abandon things that don't work. Forget about "frameworks", they can only provide suggestions, not paths to follow.

[James-egnf]

I feel like this is finally being recognized in the industry but the real problem is that Agile software has evolved to the point that it can be used to micromanage developers and obtain metrics for evaluating performance, and leadership loves this. I recently had a conversation with my project manager in which he said that he thought tickets could be written to account for activities as little as 15 minutes so that developers’ entire days can be accounted for. I didn’t use the word “micromanage” but I did use a bunch of corporate double-speak to tell him that exactly what he was doing and in no way that would possibly be productive or encouraging. Not only is that demoralizing, but it’s a very wasteful use of a developer’s time because of the overhead cost. Sometimes we need to stare out of the window and think through a solution for some time. We are not robots.

[geckoever]

You speak from my heart. The problem is: even if we come up with an Agile 2.0, if you put the same people in place as before nothing will change (which is exactly why agile is often failing)

[theexposer]

A study indicated that people trip and fall mostly at the first or last step of stairs. And it further suggested that we should remove both these steps to prevent people falling. 😅