This makes sense to me: https://agilemanifesto.org/principles.html
Everything else in the "agile" cult is bullshit.
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?
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).
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.
This is all nonsense.
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.
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).
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.