How Agile failed software developers and why SCRUM is a bad idea

Agile never failed developers, people failed Agile. Scrum is evil. Anyone doing Scrum right is actually not doing Scrum. XP and Kanban are what we should be doing.

Agile after facing corporate reality has become just a bastardization of the methodology.

I would like to know more about jQuery being outdated... i have heard the opposite also that the newer alternatives are just "bloatware"

Preach brother! You are making good points!

I totally get your point about sprint (as a time period) - it is totally broken. I was in the teams where we had so called "sprint goals" - features that need to be delivered. Trying to "close" something in 2 weeks is artificial. OR don't deploy anything before the demo because we have unstable staging (production is not there yet) yet we only have dev, so don't do anything there ;) or we just introduced something in the infrastructure which is unstable, or feature branches, yet we still need to be ready because there is a stupid demo on tuesday. So you duck-tape things just for the purpose of the demo, which has absolutely no value, because it's the end result that matters. Not perfect demo every two weeks. (because mostly it means that your team needed to slow down a bit, be a bit more cautious - which is ... not needed, you'll do faster and better with fail-fast, especially if you're not on production).

You can deploy stuff literally every minute yet you need to artificially , kind of "freeze", "prepare" your application for this exact specific time period. You literally break the natural flow of having something in continuous development that is actually the fastest way to deliver the product. Not speeding up, stopping, speedint up, stopping.

Funny thing, in previous project I was in the team where we got rid of scrum master, and our proxy ppo was so lazy that he almost wasn't present at all. So, there were only sofware engineers, qas and ... it went great. I took over doing these things, I couldn't completely remove all of these ceremonies (because other teams had it and almost certainly it would backfire us from management) but we had:
- shortest dailies
- shortest refinments
- shortest retro
- and on the demos we showed same , similar amount of features as other four teams.
- everybody was happy

Instead, we had more time to ie. call each other if somebody has some problems and needed help.

That was the moment where I realised that scrum, agile, jira, all these estimations are ... outdated. I mean, I really liked it for most of my career but it was for us software engineers, to help each other. Later it become the tool for the management, to micro-manage.

In my team, while we still had stupid sprint goals, I was saying - i don't care about estimations, i don't care about anything, we just simply need to do what is needed to be done.
We were hugely overloaded because of idiotic sales team who didn't do even a simplest discovery (so there was a miss calculation by about 300 % ;pppp).


It's like you said - these tools were helpful in the past, but later were took over in order to create "processes". Processes by the people who never wrote a single line of code, who maybe even never built something creative (i don't know, creating a song or writing a book).

ps. And similar as in one comments. It kind of instults software engineers. we're treated (many times) as some kind of kids in the kindergarden who need to be GUIDED, who without help won't do anything ;p

Management of developer teams are always looking for some kind of magical silver bullet to solve all the development problems and increase productivity. Once they think they have a good idea in their heads it's hard to get them to admit and stop it when productivity actually falls off. They might just get the idea that it's not being carried out properly and make the team learn more about the magic bullet which won't help.

I worked on Agile software project once. It was a nightmare for everyone involved: coders, engineers, content producers, media team, legal team, designers, middle managers and even CEO. Jira updates, meetings, previews and reviews, it was awful. It was more important to present yourself as productive, rather than actually being productive because managers had no clue what was going on anyway.

As a result wasting time hampered my productivity and so was the case with others. The only two people who had a blast were, you guessed it, scrum scum. They basically did nothing aside from pulling wool on CEO's eyes with flashy flowcharts and corporate jargon. The problems caused by agile they blamed on lack of agile. I left the project with no regrets.

very Agile post and reading comments make me feel as I am on Scrum meeting.

OMG! Could not agree more! Agile is turning into another ITIL and over zealous PMs who wants to control things they don't understand.

You said it! Management suck Donkey's balls...Because if you'remove that BS, most management will be debunk usless

Just think about letting construction workers build your home in an agile way

So true what you say about Jira (speaking as a developer). For me, it's often a pain in the butt, it often costs me time, valuable time I could use for actual coding... For simple time tracking, working on tickets etc, it's fine, but as soon as I have to dive deeper, it gets annoying.

Any evidence of the use of AI in the software development process? If it's not there yet, then its just a matter of time? Would very interested to get your insight.

Thanks for the "rant"! In 2005 I worked for a cie using Extreme Programming, in later cie they "transit" into Agile, all I can say is even if they (management) say "People over Process", that is only a lie.

Agile and scrum are great at making those who are unqualified feel more useful than they are. Those who get the real work done are slowed down by it.

So Scrum "failed" because it positively revolutionized software development 20 users ago and hasn't changed much since and on some teams has built up excessive crud. The proposed solution is to stop doing the unnecessary crud if you're on a small team and give up entirely if you're on a large team, but keep doing Scrum. Did I understand your definition of "failure"?

I have observed two major problems with Agile: The high degree of involvement of business users (SMEs) on a daily basis which many organisations are not able to give
2. If the project is outsourced to a third party contractor, the contractor is bound by the contract by a scope, a budget and a set of milestones that forces them to go back to waterfall process with formal documents and approvals. The idea that scope can change along the way and business users get to add and remove items from scope while trying to achieve what is feasible with the given resources is defeated.

Many comments say that daily meetings are an overhead and unnecessary. If the team is big, yes it may end up taking an hour. But with small teams, the meetings shouldn't last more than 30 minutes. I view them as opportunities to identify problems early and provide course correction on a timely basis. If your team is big, have separate meetings for different subteams based on feature set or tier of application or some such criteria. And have a separate meeting with the leads for inter-team issues.

There is literally no reason for the daily meeting. If I am stuck and need someone's help, why wouldn't I just ask them directly? Why do I need a scrum master to do that? It is literally for the manager to try to guess how much of the stuff is done. But it is impossible. If I am in the middle of implementing something, there is no way I can know if I am 60% done or 80% done.

It's an oxymoron, something that was supposed to make development more flexible and efficient just turned into an absolutely rigid, cult-like system, but it lets management micro-manage professional devs like they're minimum wage peons which is why it's done the way it is. I honestly wonder how much mandatory crunch went up since Agile/Scrum was implemented on a broad scale.

The story has been and will be the same: Wherever we look we have systems upon systems that have become the purpose instead of a support for the purpose. It does not happen only in IT companies, but all over our society, its policies, its mechanisms, its laws. We are too in love with the latest tweaks of our lives and activities to see when they do not work, or if they worked for the particular target group at all to begin with.

HEAR HEAR - I so much agree with you. Thank you fo a good video.

We had waterfall. Agile, and RUP

I preferred RUP.

It's hard to light a candle, easy to curse the dark.

This is a much too shallow rant about Scrum and Agile. There is not even constructive criticism... give some concrete suggestions how you can manage your development. Just letting devs work autonomously won't do much good in the long term.
(I don't even wanna mention mixing up Jira with Agile or Scrum, with Jira only being a random tool.)

Agile, Scrum, HRs - are big tragedy of IT.

Development within our company had always been agile in terms of constant reactions to problems and demands and the minimal use of official documentations - without even using the word agile or without thinking that it was agile.
Then came the ones with the Bible of agility and spoiled everything by spreading the word and the word and the word...

SCRUM is not a bad idea if implemented in an Agile way... but nowadays the original idea is totally corrupted.

I once built most of a fairly large project from just a set of written specs and a bunch of .psd files provided by the client and being left to get on with it. A few years later and my productivity dropped because I was having to work with a project manager on a regular basis wanting to know things like which of 100+ tickets I would be able get done in the next week on some massive bloated framework that constantly felt like a battle. It ruined the whole corporate development experience for me such that I got burned out and left the industry.

Примерно пару месяцев назад сам пришел к выводу,что agile как он используется, убивает софт. Все продукты исключительно деградируют. На этом с agile все

Never used any process besides a MAR (Maintenance Action Request). The user would describe what he wants. I would investigate why he wanted it, would uncover the aim of the requested change, would propose something different to achieve what the user is really after. The user would improve on it, until we converge towards a solution which I would then implement. The user might tyen ask for some minor improvements and we are done. User happy, developer happy.

Scrum has become waterfallified. And also overtaken by the technology for CI/CD, like you said.

Do you have a thought/observation for small teams that develop their own projects and software? I've leaned in towards a kind of pure Kanban approach, but have you seen something better or is that a good fit in your experience?

Scrum is not agile. Even though a lot of people equate the two- scrum masters get taught things that are far from the values in the agile manifesto.

I’m an old developer and I have to say this as I’ve seen it in pretty much every large organisation I worked. Some methodologies, Agile, Scrum, Lean etc. are better than others however none of them can compensate for bad management. If you’re thinking about changing management methodology you should first ask if you need new managers. If you don’t you’ll lose a lot of money.

As you said, people > processes.
Agile philosophy is not methodologies, not scrum, not kanban, none of that. As a coach, I'm very sad to see the agile buzzword used by big corporate that want to sell their silver bullet methodologies (wink wink safe).
The point is, follow the manifest, see methodologies as toolboxes, take only tools you need for your team and that's all.
It can be good, for an unexperienced team to follow a specific methodologies at the beginning, but at some point, you have to challenge it!
By the way, you should be more precise in your video : scrum != agile.

In the business for 30 years. The agile / SCRUM by th book settings I were in, were the most inefficient imaginable.
On the other hand the most successful (always a melange of efficiency and effectiveness) and quickly moving settings had the spirit of agile at their core but out of experience, not ideology.

The main driver for IT transformation in one of really HUGE financial org was Agile transformation ordered by highest levels. It took few years to train management how to manage Agile dev teams. Hoping you see the point.

So, yeah, but what do you do instead?

I once worked at company where they were using Agile. It was an awkward experience and there I learned that if a team uses Agile, run, don’t join that team, let go of that job as they are babies in the world of project management who are being curious about a toy and like to play with it. They are long way from actual managing a project!

The Agile Manifesto, charitably interpreted, was an attempt by hopeful devs to get the bureaucracy off their backs so they could do their job without excess tedium or rigidity.

Well, hate to break it to you buddy, but that bureaucracy is the reason you have a nice, cushy, well-paid job typing symbols into a machine. Nothing in the company happens outside its visibility or control. They wouldn't accept agile development according to the manifesto because while the items in the left column are nice-to-haves, the items in the right column are table stakes for a serious organization. So Agile had to be repackaged and remarketed to organizations -- as a tool for increasing observability into the software development process. Nothing in an Agile shop is done without this in mind. From the daily stand-ups to the way stories are tracked in JIRA, the goal is always to provide fine-grained observability into what developers are doing and when they will get things done. Down to the individual developer level and down to the day at least. This allows upper management to make decisions, including the reallocation (or termination) of resources and scheduling decisions, before things get out of hand. We instrument our software with things like AppDynamics in order to provide observability into our software's operations to improve performance and avoid failures; we instrument our developers with Agile processes like Scrum and tools like JIRA for the same reasons. It was never about your productivity, Corporate will take the productivity hit in exchange for data-driven insight about what you're doing, why, and when it will be finished.

That clear? Good. Now get back to work. Retro is in three hours; I hope for your sake that you completed all your sprint commitments.

My experience might not line up with some of you, but:
* I like standup, I like having a designated time every day to hear from everyone on the team and get a holistic picture of how we are all making ground each day, even if only a little, and finding out who needs help.
* Absolute SCRUM/agile dogma is awful AF, couldn't agree more.
* I agree Jira is not an "oh wow" amazing thing. I'd be just as happy with a plaintext TODO with names and dates on the jobs. OTOH there are characters I work with who absolutely need that "job assigned" structure.

I think the best "agile" outfits have made it suit them; taking the best and ignoring what doesn't work.

I'm new and not very deep into the software development world, but my gut reaction to terms like "agile" and "sprint" when I first heard them were that they felt like corporate euphemisms for "unplanned" and "crunch" because the expectations of their customers-- ugh, sorry, "stakeholders"... are unrealistic and the hypercompetitive world of software development means you can't turn down unrealistic jobs. That was my initial feeling toward those terms and some of that is no longer my take on it, but it's still about as negative.

I totally agree with sprints and complex proj mgmt tools. Sprints inhibit productivity by preventing developers from grabbing tasks as they free up time. Also a simple Kanban board is all you need. We use projectplace. I do think with teams that are geographically distributed the daily scrum meeting is helpful for team members to surface up their issues. Other scrum meetings around the sprint are useless

Sprint reviews are not demos, they are for the team to reflect on what worked and what didn't, i.e. where did we screw up during our sprint....

Dogmatism is the real problem to my POV.

Where I work, it has diverted engineering effort towards tidying up Jira items in such a way that "good" reports can be used by management to show "progress." Since our scrum master wants to advance, she plays the game by offloading a share of Jira "crafting" efforts to the scrum team members, which of course, isn't accounted for in the effort estimates!

Great video, autonomy is the original intention behind agile, specifically as outlined by the manifesto. Scrum, Sprints, and Jira are monetized products sold to management by contractors and consultants, and are the anti-thesis of the manifesto they purport to represent. `Individuals and interactions over processes and tools`; Scrum/Sprints are a process, and Jira is a tool. They force development to work in a way that appeals to management but does not produce software faster, nor is that software inherently better for it. I think the bottom two parts of the manifesto are the ones companies have adopted properly and have delivered great results steering away from waterfall practices, but I really wish we could see more of the first and second for the developers sanity.

My man, thank you so much for the video! It's so sad and so true...

Agile is the fastest way to produce burned-out developers alas 👀

Jira is good at tracking support tickets. Using it for projects/dev work is a misunderstanding. Scrum? All I need to know is that a woman who never wrote a single line of code, can be 'scrum master' and drive programming projects. And programmers leave left and right, because they are expected to deliver 'Moon on a stick'. I have a 'project manager' in my current job who drags me on catch up calls every week, asking for progress reports on projects I don't even have time to touch, because I'm so busy with other projects, and rather than talking about priorities, shuffle stuff around, she just says 'so what, next week then? I'll schedule something'...