Negative developer comments about Agile and Scrum on social media
github.com
github.com
The problem is not and never had been agile. It is the "agile" industry which spun up around it to bilk clueless management, out of money and give Execs reasons to transfer a couple thousand quid to their buddies for agile consulting services.
Agile is brilliant precisely because it is so concise and clear and there isn't that much more beyond the manifesto to understand.
Unfortunately it was mangled, tortured and twisted into a Frankenstinian nightmare that made everyone suffer. The good news is that right around the time everyone was getting wise to the fact that the entire agile industry was built on sand DevOps popped up to be the new buzzword of which the kingdom of jargon will be grown out of. And the cycle continues.
Scrum is the epitome of this. It's a half-measure that combines the worst of waterfall and agile. You have (almost always) pointless ceremonies that do little more than satiate management's cargo cult of productivity (yes, I do know what it is academically designed to do). Furthermore, given that its more similar to waterfall than kanban, it often gets watered down for execs and becomes even worse.
I have come to realize that unless you're doing something that approximates kanban or chaos/anarchy, then you're probably not doing agile.
- It's good for interfaces. Specifically, ones that are ill-defined
And therefore, agile is great for moving around widgets, changing CSS / colors / fonts, adding a widget or two, improving validation on fields, maybe splitting a page into multiple. Notice how all those tasks are palpable, pretty simple, well constrained, evolutionary, and steadily improved? Perfect for Agile.
It might be good for some microservice development, but it also tends to make microservice interactions unstable and explode their numbers, and destabilize the apis.
Research, deeply difficult code, inherited codebases, large refactors, architectural migrations (monolith --> microservices, major version updates to platforms, move to cloud), are AWFUL for Agile.
Aside from that, story points, burn charts, velocity charts, fixed sprints, tend to be square peg round holes and big hammers. I can't count the number of times I simply had a "8" ticket that would cross two or three sprints before it was done, and eventually managers just accepted it when I explained what needed to be done. And really, that was still to confining for major major tasks.
Also, QA gets completely squeezed, because the agiles I've seen all assume the QA is done in the same sprint the dev occurred. Wow is that dumb. Because the dev runs long, the QA gets shrunk. Really the QA should occur in the following sprint once the dev deadline is achieved.
There has to be a middle ground. Either you are doing 6-12 month waterfalls, or doing 1-2 week sprints? Come on people. How about 1-2 month checkins?
Sometimes I wonder if software dev orgs could vastly benefit from a bunch of attached "dev assistants" that help write the documentation, track tasks, tickets, etc, and alleviate devs from having to do all that paperwork / distraction. They can function as safe sounding boards, or keep an eye on a bigger picture as the developer dives deep into the tech details.
Managers wouldn't stoop to this. SCrummasters ... kind of ... devalue managers a bit at the interface point with engineers, but not enough to get this sort of bookkeeping.
Like, if you are shelling out 200k for an engineer, wouldn't you rather they work as much as possible on the tech stuff, and leave the bookkeeping to some cheaper person?
You can’t really teach beliefs, which is why it’s formatted like an agreement. Everyone is supposed to at least think they share these ideals, and make choices that align with those beliefs. But that’s much too introspective to be marketable as meta-work, so people have started reading between the lines to explain away specific meetings or processes. Because “agile” as a concept is so unclear, it’s easy to expand on, creating the weird Frankenstein situation you’re talking about.
And a lot of those comments sound like whoever is handling project management uses Agile as a dogma rather than a toolbox to be modified as needed.
I don't think I've ever come across a project that uses "pure" agile. It'd be pretty insane. Right now I use a mixed approach that uses: * Requirements * User stories * Use cases(IBM style) * Planning Poker * UML * Sprints(Both 1 week and 4 week sprints) * Burn-Down charts And a bunch other I'm probably forgetting.
It also sounds like their project managers aren't actually managing them, but rather delegating the management to their developers.
I used to have a producer that said that every second an engineer wasted faffing about in JIRA was a second not spent solving an issue, so he tried to automate reporting as much as possible and wanted us to only raise an alarm if something didn't go as planned.
I quite liked this approach and I'm planning on using a modified version for a future project, so I guess I'll soon find out if it works :D
Instead of time-sheeting, they were using agile story points, without understanding that the whole damn point is that one point in one team could be worth ten points in another team.
Everything else in the "agile" cult is bullshit.
> Everything else in the "agile" cult is bullshit.
IMO the fundamental problem with the manifesto is the question, who is the customer? "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
My customers don't want "early and continuous delivery". I hate App Store apps that release new versions every week with cutesy uninformative release notes like "We've improved the software for you". That's bullshit. And users don't want "early" half-baked buggy crapware; they want their software to Just Work™.
The Agile Manifesto seems designed for contractors or for wage-slaves to middle-managers. Replace "the customer" with "the end user" and it doesn't sound so great anymore. But nobody seems to care about the users of the software.
let me translate that, "we rushed our previous release to meet some arbitrary deadline to make some manager look good, but here's a release to finish some of the issues we knew were left incomplete while we all collectively held our breath that not enough people would run into the known issues"
at least, that's how i interpret it
How many times do we have to work evenings and weekends for a bullshit deadline, and then see that the user doesn't start using the feature for another 4 months, if they ever actually use it?
Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack.
For large dev houses those service packs were complicated and hard to ship, because their entire organizational structure was based around big bang releases.
Competitor comes out with a killer feature? Well users of your software weren't going to get it for literally years, during which time a fair number of them might very well defect to the competitor's software.
And a lot of software you use gets updated all the time, you just don't notice. Performance bugs get fixed, memory leaks patched, and UI quirks, that you may not have run into, are removed.
It still would if you had to go print CDs. The internet changed all that of course. Now we have a business model based on continuous sales (like app stores instead of big launches) and subscriptions.
Which allows us to ship bad software and hope that we will fix it later (spoiler: we never really do, it usually stays pretty bad).
Did you experience that, or did you read it in one of your Agile bibles? Genuinely interested.
Windows releases, Office releases, Visual Studio releases.
I started my career in the mobile (originally Windows CE) compiler team. Releases were a big deal, support contracted lasted seemingly forever. (Ironically, internally the mobile compiler team was actually very agile, with weekly full test passes happening, the compiler always being in a shippable state, and development occurring in what would now be considered modern practices.)
Microsoft was getting destroyed because they were very non-agile. As soon as the iPhone came out, Apple started releasing a new OS every year, and back then OS updates had significant developer API improvements. Windows Phone couldn't complete with that. I remember how lacking the camera API was soon as instagram types apps with filters came along, Windows Phone went from amazing to instantly behind the curve.
Look at what happened to Hotmail when GMail came out, it took Microsoft years to catch up just with the storage space increases, UI improvements took even longer. Microsoft ended up losing their top spot in the webmail game.
Internet Explorer (eventually Edge) was tied to OS releases. Even when MS started to invest in their browser again, being tied to OS releases meant it could never complete with Chrome releases happening every few months. Edge would have a big release, pull ahead on benchmarks, then 6 months later be out of date and behind the curve again.
Agile forces code to always be in a shippable state, which is a good thing. It doesn't let code become bug ridden and then say "we'll fix it sometime later".
That forcing function alone is a huge improvement.
Is it Agile, though, or is it Internet? Because having the possibility to send regular updates over the Internet seems to have permitted to ship buggy software quickly, and pretend that it will be improved later. That's faster, but I feel like software is lower quality today than it was years ago.
This is all nonsense.
Nope, we care about money :-). My feeling is that software has been becoming worse every year since I started writing code (that's 20 years).
They were happy with the result. I was happy I could act as a force multiplier for an entire team.
That’s what Agile is supposed to be.
Everything else is some weird cult.
Like… Jesus just told everyone to treat each other the way they themselves would like to be treated. The specific dress code of the bishops in the Vatican? That’s not the message. But I guarantee you that the dress code is enforced by some busybody.
But then does it have to be called "Agile", or can we keep the older "common sense"?
I tend to think that at university, we were pretty good at self-organizing for group projects. We had to be efficient because of deadlines, and it worked well.
Then I joined a company, where some people (usually not the best developers, obviously) felt good telling everybody else how they should work. Introducing processes, reading all sorts of agile books, copying Spotify's processes, using the management tools they saw in a Netflix blog. Those were the managers.
And every time I ask a manager: "so, this process... is it to make you more productive, or is it meant to make me productive?", they say "it is making you more productive". Why would they believe me when I say it does not? Their job depends on it.
Anyone I’ve had to work with who has “Agile” in their title has at best done nothing, and at worst slowed everyone to a crawl.
The base ideas though, I totally agree with.
I think things fall apart (ironically) when “agile coaches” put processes before individuals.
That's probably the most useless (and counter-productive) role I can imagine. Usually people who can't build anything interesting themselves, but realised they are good at bullshitting others.
Every team I have ever been on has had zero idea how to run an effective Agile team. They don't know Agile, Scrum, Kanban, they've never had project management experience, they don't understand why they need estimations, work limits, reports, continuous improvement, stakeholder management, or really any concept out of "Me write code good!" Left to their own devices, teams are shit at communication, shit at process, avoid anything difficult, and end up needing some clueless outside manager or contractor to force them into a process so they'll get something meaningful done on time and actually report it to someone outside their group.
If everyone on the team has had real Agile training, and actually practiced it before, then they can manage their own team effectively according to the principles. But that team does not exist. Managers don't understand these principles either, and won't ask for the things that ensure the principles are followed. Really everyone is just fucking clueless and doesn't care.
Some think Jira means agile, others think exactly the opposite, that use of Jira is an affront to agile. Some think that you don’t need requirements in agile, others think that without requirements there’s no agile.
It’s been my experience with similar threads in the past - that even the commenters weighing in on the subject will ultimately fail to agree on a common set of definitions and will end up with varying and often contradicting interpretations.
A fertile ground for a ministry err… a consulting business offering thought leadership.
live and work long enough in this industry and you’ll go through myriad of “processes” and “manifestos” and other bs all created to hire tens of thousands of incompetent people to tell 100’s of thousands of (mostly) incompetent people how they should do their work
Beyond that, there never seems to be anyone in these stand-ups that is capable of helping me because I'm doing stuff that nobody else in the company knows how to do. I'm learning as I go. So the meetings just tend to be me droning monotonously into the ether for no reason. If they did a quiz at the end of these things, everybody would fail it.
Also, engineers tend to have social anxiety. That's why a lot of us became engineers in the first place. It fills me with a small sense of dread knowing I have to speak publicly, every single day, and that creeping dread basically ruins my productivity in the hour of my morning before the meetings start, too.
I'm a lifelong nerd. I don't need motivation to make things. I don't need a 2 week learning period at the end of an iteration or whatever. I learn all of the time because I like to learn. I like to tinker. I like to automate things and make them more efficient. I deliver value just by getting the toys I want to play with.
Maybe Agile makes sense for lazy developers, but that's not what I am. I'm a force multiplier. You know how the special operations guys in the military get to have beards and hats and sunglasses? That's because they're not neophyte grunts trying to fake insanity to get out. They are highly skilled and they get shit done, so they get left alone to do their thing.
Agile feels like it sacrifices its special forces to make NCOs and ensigns look better. Sorry for all of these military references. I have no affiliation. I watched Band of Brothers a few times. It's just the closest thing to a human loss factory that I can think of.
The thing is management doesn’t view developers as special forces. They don’t think we are Obi Wan Kenobi. They think we are Jae Jar Binks and they can always order more developers and Congress will literally drop ship them into awaiting open plan offices. The bizarre thing is why don’t they hire these very same developers remotely instead of H1B? Well you see they don’t think we are Obi Wan Kenobi…
The internal incentives in hierarchical organizations is to balloon the management, which suffocates the bottom of the pyramid. That's just how the world works, for most people, not just SWE. The Agile is horrible because corporate management makes everything horrible.
If you don't like it work in a small, carefully selected startup, or make your own company. Otherwise just accept that you're just a corporate drone and you have to endure the shitty corporate system to pay your bills. At least you get paid decently, because there's not that many people to replace you like in other professions.
Unfortunately very few. Which is probably why people hate agile in the first place. The problem is not agile per se, it's the management.
If nobody can do it right then it doesn't matter if the methodology produces utopia when applied correctly; nobody will ever get there.
The first few I see are specifically about aspects of the scrum framework, even if the word used is "agile". The correct response to those issues at least, would be too highlight that there are other versions of agile that aren't scrum and advocate for trying those instead - which is the exact opposite approach.
.
Also the point of agile is flexibility rather than efficiency or throughout. Favoring flexibility means delivery erring on the side of overcommunication and is inherently prone to micromanagement.
Addressing that issues is also not served by telling people that can ignore everything if they're one of the few that knows that agile isn't limited to just scrum.
Next thing, people started building runways in the middle of the forest and expecting planes to arrive with crates of goodies.
The simple people, thinking there are solutions to developing complex software that they can simply apply and boom:
There are methods that work and that don't require institutionalized estimation-bullshit. For instance:
- You write a mobile app for a customer. Discuss the requirement with them, say what is "easy" and what is "much harder than they imagine" (they probably don't want that, it's orders of magnitudes more expensive than they expect). Then work hard on limiting the scope of the project with the customer and start working. Meet every 2 weeks with the customer, show the progress and get paid. Decide the next step with the customer and go for another 2 weeks. This is the closest I can imagine to the typical Agile cults, except that it doesn't involve estimation dances ("Fibonacci points or T-shirt sizes?") and all the "velocity" crap.
- You need to write bigger software than a small app. In that case, just build it slowly, and start selling it when it is ready instead of selling promises based on estimates (again: estimates are wrong). Estimates here lead to over-promising, then there is no need to design the software properly, everyone makes hacks and rushes and makes a bad job.
They work in fixed-length sprints with daily standups. They assign bugs to specific people who then have to write user stories about the bugs before beginning work on them. Product features are planned out quarters in advance.
You know, Agile.
Is this a thing? I can’t imagine a build step that takes more than a couple hours for even the largest project.
I find it really funny when people complain about politics, when those people have never and will never do anything to fix the problem they're complaining about. Like complaining that it's too hot outside, but still sitting there in the heat.
And what's really funny is the only people who comment on it are the people who have no clue how it works.
What do you know? Because somebody is not in a position to change the political system, or is not able to propose a better system, does not mean that they can't see problems.
I hate the "I don't want criticism, I want solutions" idea. Identifying and acknowledging a problem is the first part of finding a solution. Those who refuse criticism are just denying the problem.
For a political system, you need to convince many people if you want it to change. You can't just "move on to solutions".
For agile in a company, in my experience the developers are not the ones bringing the processes, and they don't really have a choice. And even then, again in my experience, juniors tend to get excited about everything that looks new. So part of the team will think that estimations are a good idea in principle. Until they do it long enough to realize that the whole methodology is a big joke.
Any team that is dogmatic in how they develop software will always have a difficult time.
Teams should ask what problem they’re trying to solve, and whether “agile” has some tools they could try to improve their problems.
There is a religion called "The Agile", I would say. Agile coaches are their priests.
Just last week I had a client request that I create a “user story” for my access to a system so I could actually work on the project. It can get crazy out there.
And the catch-22 is that only things that “deliver value” can be user stories, only things that are user stories can easily get into backlog, and only by doing things in the backlog can a developer prove they’ve done actual work that justifies them continuing to have a job at the company.
So to get around this restriction for something that isn’t a user-facing feature, devs have to be creative and you end up with these completely insane-sounding user stories like “As a user whose data is stored in the database, I would like the database schema to be overhauled so it can support a many-to-many relationship”.
Agile fails because it gives management fine-grained control over developers’ todo lists.
DDD and agile don’t like each other much at all until you’re in the implementation side of software engineering. The discovery and modeling activities are very hard to quantify so reporting tasks and progress is very difficult.
So the challenge is to get managers to be flexible in how they manage aspects of application modernization.
Agile has nothing to do with things being easy to quantify (except insofar as it is in part a response to the fact that they aren’t, generally, in software development.)
Obsession with quantification and detailed estimation is something Agile was a response against (but which has defeated Agile values even in most places that say they are “Agile”.)
DDD may be an excuse for (it does not seem to me to actually require) big upfront design, rather than the more fluid minimal units of independent value many approaches in the agile space prefer, but that’s a different issue than quantification.
It's much more important to stick to dogma when you have 200 guys that need to coordinate. Anyone overmanaging your team of 6 sticking tightly to agile is wrong. But similarly doing cowboy type anything goes "requirements are a suggestion" type stuff causes disasters on the regular at larger companies resulting in knots that are far too large to untie
Maybe in a properly run shop it works and I have just had poor luck.
If people actually believe that, you should be MORE aware of customer needs, what the market your company exists within is doing, and why things have to be done.
It’s not great if you don’t want to have to worry about outside factors like that, but then you need to expect the many extra managerial and planning layers that will worry about those factors for you.
My opinion is that agile needs to be agile, in that we have to adapt ways of working based on the team’s situation, what were working on, how well resourced we are … and have agility to change how we do things to optimise our work based on those constraints.
“This agile witch hunt has to end, but it never will unless we start politely asking for the things we want.
i know for a fact that 90% of engineers dislike agile but many don't even imagine there can be an alternative, and most who do are terrified to say anything. Just look at the other answers to this question, most are from the very non engineers that have imposed this nonsense in the first place.”--Anonymous,
Most everything else that’s been written about agile has been pure propaganda that you’re not allowed to question. There needs to be other viewpoints that are critical of agile.
Students tend to learn to do that in university group projects. Then they join the industry and we tell them "you need to gather everyday at the same time for what we call a 'stand-up', where we talk to each other". Guess what? The students were communicating without having to make formal stand-ups, and it worked.
- Have somebody who is responsible for understanding the customer from a business perspective and be able to explain that to developers in the form of prioritized development items.
- Try to build something that works to confirm your assumptions and manage risk, ideally on a short-ish cycle of a few weeks. Always keep a working product. In some projects this is not (immediately) possible - in that case, it’s probably better to run a traditional waterfall-project, with the tradeoffs that come with it.
- Get together regularly to talk about less immediate topics and improve the work process.
- Plan and make forecasts using actual data from the past, not wishful thinking.
And that is basically Scrum. For me this is common sense, I wouldn’t know why you would do it in another way.
How it’s implemented in practice differs and it seems a lot of places don’t implement it very well. So far I haven’t heard many good suggestions from the developers suffering under these implementations on how to make it better though, hence my question.
The devil is in the details. The problem is the cargo cult that goes with Agile. You can take any example that works and say "this is Agile!". But in practice, what happens with Agile is that some people come with their book that they treat like a bible, and try to apply it without question.
I have had teams where we were communicating really well, but still we had a 40min standup everyday where we would basically say "as you already know, <blah>". Still we were doing standups, because the bible says we should. We could have used that time for a coffee with the team instead.
I have had teams where people were working on very different things, so nobody would listen to the others during the standup, and during the planning, it was 10 times a 1-on-1 with the team lead because nobody really cared about the tasks of the others. Everyone but the team lead was losing their time. But the team lead found it useful (obviously).
One of the best things about CI was knowing who would deliver and who wouldn't and who knew their stuff was so important they could break everyone else's.
I just see the agile management processes as an attempt to get the same insight outside of the code base.