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

236,985
0
Published 2024-06-17
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.

www.engprax.com/post/268-higher-failure-rates-for-…

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?

All Comments (21)
  • @awesomeworld557
    It's failing, because agile is being used to micro-manage people
  • @rccc5806
    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.
  • @imagiro1
    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.
  • @vishnunallani
    I still don’t understand what a scrum master does and why they are needed
  • @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. :)
  • @kylek29
    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.
  • 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.
  • @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?
  • 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".
  • @user-vr2rq5hl6l
    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.
  • @javaman2883
    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.
  • @olber289
    Very interesting video. I’m in IT (but not developer) and day 1 when agile came out I said, this will greatly stress and put under pressure developers, this is not a good method as it is…This need to be changed because at the end this is human beings..
  • 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.
  • @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.
  • @katchF22
    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.
  • @MilMike
    I have been a dev for over 20y and a year ago started to work for a company which does the scrum stuff. Your video exactly shows how I feel about it. Biggest problems are the constant meetings. When I started and I saw my calendar, I thought it was a mistake. It looks like I am a some kind of busy business man with million of meetings. I feel burned out. Already searching for a new job, but most of the companies nowadays use "scrum", which is depressing.
  • @petebrown6356
    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.
  • @gtrbarbarian
    I'm a CSM. And a SE and Architect, 30 years in the biz. Agile is a way for consulting companies to make $$$. Most companies do not even do full Scrum, they use daily standups as a way to micro-manage. Full scrum has roles that (barely) make it work as a methodology. Remove those roles (program manager for instance) and failure is inevitable. I did just fine for twenty years prior to scrum, using waterfall and then rational unified process based on use cases. Use cases worked, and identified wtf you were building. The fallacy is that scrum produces working software. It may produce some software, but it rarely produces what the end user actually needs. It also makes engineers have to basically apologize (in toxic environments) for research spikes, requirements gathering, architecture or any other fundamentals of software engineering for which there used to be formal process. Software engineering practices are on the decline. See 737 MAX, and be very afraid.
  • @gecko4ever
    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)
  • @iamblaineful
    As a former Dev, now CIO/CTO, we do Agile Lite. We let the customer (internal employees) stack rank, we build what they want in "functional phases"...maybe you call that Waterfall, Sprints don't have a deadline decided by me, it's not 2 weeks hard and fast, and we work our backlog. We have happy customers getting what they need and have measurable progress. You don't have to buy into the cult. Maybe the sprint is 5 days, and maybe it's 3 weeks, I don't care, and why should you? In either case, we have to stack rank so the customer feels they are getting the value, but outside of that, I'm not giving you a full delivery schedule because your requirements are not fully qualified. People can't articulate requirements until they use it, so we eat the elephant one bite at a time.