'I Hate Agile!' | Allen Holub On Why He Thinks Agile And Scrum Are Broken

Allen Holub gives strong opinions on agile and scrum and how their adoption can cause problems within software engineering teams.

-------------------------------------------------------------------------------------

Also from Dave:

🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧

_____________________________________________________

🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS

-------------------------------------------------------------------------------------
➡️ Links:

-------------------------------------------------------------------------------------
📚 BOOKS:

📖 "Continuous Delivery Pipelines" by Dave Farley paperback ➡️

NOTE: If you click on one of these Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

[ringorango]

I see most of the people who are forcing agile and scrum are business/management people. Similar to any other management certification. They took it as an opportunity to legitimize their position without knowing software engineering at all. They instinctively understand that their position doesn't produce any value rather than running the corporate hierarchy. So they need something else to be seen as doing something or bringing value. And since they are in the management, they shovel it down the throat of the actual developer who suffers from cleaning up all the gaps pushed down the project hierarchy. And dev who are not good at technical or can't withstand the prolonged stress change career to become agile coach/scrum master/product owner or any non-programming role. And also those roles have a better chance to climb the corporate ladder compared to the programming role. Then we start again the cultic cycle.

[tristanmills]

Having gone through an 'agile transformation' which handicapped an engineering organisation which was pretty agile and effective, this resonates a lot.

[MoisheLettvin]

My god, this is so refreshing to hear. I've been writing software professionally for 35+ years, and witnessing the cargo culting of Scrum and the way it's infantalized what software engineering is has been frustrating and, honestly, a little heartbreaking. Writing software can be so creative and powerful when you're part of a team focused on building something amazing, and the layers of process and "ceremonies" around it sucks the joy out of it.

Thank you for talking about this.

[Atr]

I'm a heavy introvert and find overcommunication too much, Scrum is something I also despise. It causes over communication which is leading me to be burned out and loose all motivation, an endlessly growing list of tickets and stress, I don't like talking to people too much and when were talking its making me loose focus on programming

[JustLikeBuildingThings]

The whole certificate culture is bewildering. Companies hiring folks who've passed an online open book exam over those with real experience delivering software and doing the roles.

I actually booked the wrong exam by accident and still passed...

[davidburris]

My experience with Agile/Scrum is that it's implementation constitutes all of the things that the originators said NOT to do. Pile on the concept that in product development involves estimating Jira tasks for yet unknown implementation details for features never done before, standup meetings that on their face are status meetings, more meetings for accountability when schedules predictably slip, and what you have is stressful results bordering on abusive.

[vanivari]

A car manufacturer in the far south of Germany uses a scrum model, where EACH STORY is a fixed price contract and the only way a provider gets payed. If a story takes longer (or there are any bugs), the provider has to pay for that out of the own pocket and if a story seems overestimated, there are tons of discussions with the POs. This of course results in a lot of "management" on provider side because if stories are your only income for everything including managers, scrum masters, BAs etc. they start to monitor heavily and annoy the team with all kinds of pre-plannings and pre-reviews and "status-checkpoints". Everything in JIRA + Confluence + Excel lists. And every "spill-over" is a giant drama, which requires even more bookkeeping and discussions. And god forbid that you don't deliver the ordered SP over multiple sprints, because then the customer starts all kinds of additional monitoring and tracking because the release might be in danger. And of course all developers have 0-2 years experience and each team has a scrum muster who never developed a single line of code, but has a certificate.
SCRUM was never a great experience, but not even a single year in that car company burned me out like crazy - I'm so done with SCRUM and agile in big corporations. And all that for a bunch of backend systems which must be ready in a year (of course as microservices...), so many aspects of scrum don't make sense anyways. But then you get stories like "As system A i want a masterdata batch job so i can transfer data to system B".

So personal ranting aside, i see a giant software crisis ahead because every year we throw more unexperienced developers into unexperienced teams, give them an unexperienced "scrum master" and a Cargo-Cult-like process and let them build software, which is not maintainable anymore after 12 months. No specification, no documentation, just unreadable unmaintainable code. I guess I will spent the rest of my career reviewing and firefighting projects and maintaining unmaintainable messes.

[_winston_smith_]

I think the root problem is one of competence. If you have a small group of highly talented engineers who work well together then almost any process will work. So you have very skilled people defining a light weight iterative process and some basic principles as “agile.” Then you have a mass of management and mediocre software developers trying to apply concepts that, while simple, they don’t fully appreciate. Most software developers think they are great. Not everyone can be the best. The majority are simply code monkeys. The folks who defined agile originally are probably all really smart. Often smart people underestimate their own ability and drastically overestimate the ability of the average software developer.

[Metalblowing]

Our team got a new scrum master recently.

He came in with a list of mandatory practices that cannot change. I asked about aligning some of the stuff to our business model to ensure that we deliver value more efficiently - he replied "we can't change this because these rules are fixed in stone". Okey, Really agile.

[recmtnbiker]

If I was a student majoring in computer science, I'd take math classes such as liner algebra and a statistics class with calculus as a prerequisite as well as some electrical engineering classes and look for jobs in real time embedded software and more math intensive products like inertial reference systems. You don't have anything until almost everything is nearly completed, which makes these product lines more scrum proof.

Working as a software engineer was better back in the 80's and 90's before agile scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of agile scrum until 2016. I worked at a job that does agile scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With agile scrum and the pointless daily morning meetings, employees are treated like six year olds. I just started working what will probably be my last contract job before I retire for good, with a former employer that makes inertial reference systems in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing agile scrum. It is good to be able to work autonomously and be treated like an adult.

[TheMetadude]

I can only echo this. I have worked with / for several companies using "Agile and Scrum" and in my experience it's been a tool used to micro manage the development process and give managers (BTW I have managed teams myself) the illusion of regular progress and control. In these companies progress was measured by the completion of artificial tickets and lots of time is wasted with inefficient tools like JIRA.

I'm sure Agile and Scrum is properly implemented somewhere but I haven't seen it myself yet. So when a company empathises their "Agile process" I get suspicious. When they start talking about JIRA I get worried because. If they have a scrum master I am genuinely scared !

[jkuang]

I have said many times before and many years ago, Agile and Scrum is basically MAKING SOFTWARE LIKE ASSEMBLY LINE. It is a process to force the creative software developers to chase one task after another on tight schedule controlled by management. Yes we all know schedule is tight, but once you try to solve the problem using ASSEMBLY LINE process, you are creating a chaotic environment that resulting in mess.

[stingyhatgames]

As a software engineer, I've yet to see Agile succeed in the workplaces I've been in that tried to implement it. And the failures have been spectacular and would be funny if they weren't so painful to have to live through. I've seen grown adults cry during stand ups, and retrospectives devolve into finger pointing, name calling, and even chair throwing.

[paladinsorcerer]

My first experience with Agile/Scrum outside of college was as far as I know a full-on implementation of the techniques. So I feel that I can speak to Agile/Scrum. My first understanding was that Agile/Scrum is a way to allow developers to sort of manage themselves, with acknowledgement that they can't get away from management completely and therefore tack on the idea of accountability to make it fit in a business context. But instead it has become a way for the business to micromanage developers. Agile/Scrum, I thought, was a way to identify work that is blocked or not working, and to fix it as a group. But In my experience it was not always done with the right attitude. Agile/scrum techniques are meant to quickly identify developer problems. Since everybody is different, all developers have different abilities. And so developer problems can also look like problem developers; problematic or underperforming developers. It can put rockstar developers on a pedestal, since they are responsible for making the burn down charts look good, and incentivizes those developers to look out for themselves. Instead, you have to have the right attitude, so that solving problems as a group means working with the group that you have. If you don't do that, it incentivizes developers to cut corners, in order to make artificial deadlines, and so you end up with bug-driven development instead of high quality code. The same goes for deadlines, where strict adherence to deadlines incentivizes mediocre developers to avoid taking the time to build in quality, and to cut corners instead, since only the top performers can be safely transparent.

[LAICEPS]

I have been working without scrum during the last three months, and they have been the happier months in the last three years. Also I have delivered more value than ever. The last time I was that happier in my job and in my life was before using scrum in my first project.

[Ian-ebio]

There are some serious problems with extreme programming. Having people sit close together without any privacy or personal space. Which is then contradicted by wanting people to be focused and free from distractions. Then there is pair programming, the perfect way to induce increased stress, fatigue and ultimately burnout. It is a practice that takes giving people no privacy or personal space to it's extreme. These practices seem to be driven by people who have no need of personal space or a quiet place to work.

The problem with scrum is that it becomes a cult focussed on the ceremonies. You may not abandon the ceremonies even when you don't need them. It is also common to blame the implementation when it goes wrong while simultaneously attacking a parody of waterfall.

[lairjuniortv]

They are broken because companies got the agile manifesto, throw everything away and kept only the “respond to change”. Who needs working software when we can push to delivery even with cumbersome release management processes? Who needs to talk with clients when we can have a surrogate called Product Owner.

[alichamas]

The problem I've seen with Agile (particularly in larger business) is that it's a methodology primarily for management, not for software engineers. Software engineers become disempowered under layers of middle management ceremony, and product owners are often so far removed from the actual production of the software that they equally become disempowered. This leads to a true lack of actual ownership and quality assurance yet it looks good and sensible from a line management point of view (and there are lovely graphs!) so it's the defacto tool of choice for big tech brother. Nobody uses it on smaller more passionate projects which are often far superior in quality, as they actually care about what they're doing.

[daverooneyca]

I watched this video at a 1.3x rate... every time Allen & Dave laughed together they sounded like Beavis & Butthead, but in a good way! 😂

[davetoms]

As a certified Scrum Master I actually love a lot of your points. Just my experience, but I've found elite teams don't need a framework at all; excellent people driven to work together just get it done. But far too many people - both on the technical side and business side - need to be dragged into complying with transparency and regular inspection. Even as a Scrum Master I would drop Scrum in a heartbeat if a company embraced most of the 4 Agile values and 12 Agile principles and embraced the idea of not only continuous delivery but also continuous (or more realistically, somewhat frequent) improvement to how we work. Almost all the Scrum hate I've witnessed first hand has, upon deeper probing, been frustration with how Scrum exposed underlying organizational problems that needed addressing regardless of what framework we used. For me, Scrum is like training wheels for both business and technical people on how to work together. Once we embrace a path to continuous delivery and sincerely asking on a regular basis "How can we do better?" then all the ceremonies and buzz words can go away.