Agile has failed. Officially. Now comes version 2
medium.com
medium.com
I could quote a ton of stuff that Cliff said at conference dinners and parties in the last years, but really -- would anybody believe the world is flat?
That guy lost his marbles decades ago.
It's interesting that you can read from every single "agile is dead" rant that the author has abso-elfing-lutely no personal experience whatsoever, and is just using it as click-bait. :sigh:
What Agile does to your best people is just next level cruel. They are bombarded with constant meetings, status progresses, forced to be playing childish games with cards, and are being "led" by incompetent snot-faced BAs who happened to finish a single week's course and suddenly became certified SCUM masters or POs. Thus, your best people either leave or are rendered powerless and incompetent by the mire of mediocrity and cult-like ritual following that SCRUM drags you into.
One thing I can never forgive Agile is that it claims to be one thing: "people over process", but then just goes ahead, and it's the exact opposite. It goes and defines a gazillion processes and its practitioners scream bloody hell if you don't follow them, because then it's "not real SCRUM". Let's be honest what each thing is.
- Standup is a scheduled management upgrade, so the manager has some progress to report.
- Planning poker is a useless waste of time so the manager has some false sense of security when something will be done (usually badly and incompletely). They will share that info with other managers, who will add that in their calendar as a deadline, and then will blame the devs when it fails to materialize on time. The real culprit for the delay, of course is obvious. It's the fact that the devs spent more time in meetings estimating things and explaining to the walking tool that is their PO why it's not so easy to simply do X or Y, instead of actually doing real work.
- Retrospectives are actually useful, if the manager is out of them. By retrospective I mean all iterative methods of improvement, not only every sprint or every incident. All types of structured or unstructured improvements are good.
- The Scrum Master role is made so the owner's son has some well paid work to do after dropping out of college. Also, the role was created and because some old dudes wanted to sell courses online or books, costing $$$. This should go to show you that making stuff up as you go into random processes and then writing a book about to give it some validity is a totally viable career in life.
- The PO role is where the money people (vaguely called "Business" or "Stakeholders") wanted to initially give agility to the devs, because they read somewhere it's nice. However, after giving it some thought, they thought better of it. At the end of the day, they decided that a person with no technical knowledge and no understanding of the inner workings and details is a much better qualified decision maker than any of the people with intimate, in-depth knowledge. After all, a totally incompetent dumbo's mindset is much more relatable to the "Stakeholders" than those pesky devs, so of course they are gonna trust the PO's "wise" judgement.
- Sprint is just a cleverly crafted ploy to make the developers endlessly hurry towards endless micro deadlines, sprint after sprint. Who sprints all the time, all year round? Sprints should also be called "The Death March". The way sprints break down everything in dismally small pieces also serve as an excellent reminder to the devs, that just as they are replaceable cogs in the machine, the thing they are building is just a bunch of badly fitting factory assembled parts.
That's to eliminate any illusion that our work requires careful curation, ownership, ingenuity and patience, and that it's a craft. No, our work has to be thought endless sprint from one small insignificant feature to the next, in the pursuit of "value" (much like factory workers produce parts with repetitive moves, day in and day out).
- Agile Coach role. I have to admit, when I first heard that there exists such a role, and that people have it as a career, I was out of words. The mere fact that there are people who are "agile coaches" and that there are companies who employ and take the service of agile coaches is a solid proof to me that humanity's days are numbered.
Agile and Scrum, like every other religion, are basically the result of people giving up thinking for themselves and wanting an easy packaged guide to follow from snake oil salesmen. Such easy cures could never do anything but disrupt a company. Nothing can beat smart people thinking and communicating, because dumbness is not curable.
"Standup is a scheduled management upgrade": Nope. The manager isn't even there during the standup.
"Planning poker is a useless waste of time so the manager has some false sense of security when something will be done" Nope. It gives the team a chance to see what's coming to them in the future, and a feeling to guestimate the work needed, so the less experienced people have a better chance to participate in the sprint planning.
"Retrospectives are actually useful, if the manager is out of them." Yes. Retrospectives are a safe zone, so if your manager even tries to join them something is wrong. They do get the consolidated, actionable items though, and are responsible for helping to fix them.
"The Scrum Master role is made so the owner's son" The Scrum Master is not a role-job. It's a role of the day, and every member of the team will take their turn.
"The PO role is where the money people..."
Ah. Worked with one bad PO before? The PO is there to help the team, and highly incentivised to do so. If he is not doing his job, in answering the questions they have and unblocking their work, the team will leave him hanging dry for a sprint or two, and he is gone.
"Sprint is just a cleverly crafted ploy to make the developers endlessly hurry towards endless micro deadlines, sprint after sprint." Wow. I see some major depression there. A sprint gives us the chance to tick a box every few weeks, instead of achieving nothing over years.
"Agile Coach role." Really? That is a role at your company? It's amazing what an Agile Coaching consultant can achieve by visiting 2-3 times a year, with an outside perspective. If they are there full time, and paid like everybody else, they loose the outside perspective, and thus are not a Coach, but something ... weird.
Is Agile the holy grail of perfection? No.
Is there anything else that gets even close? Hell no, but if you know a framework that works better let us know.
It's always easy to say "X doesn't work", the real constructive part is to be able to say "Y works better than X because of Z".
Ah, yes, I've heard that before. I am simply not using the "proper scrum", right? And the agile coach you just happen to know can show us the way, right?
Sorry, but I've been in the industry for 15+ years, last 8 at a senior position (VP of Engineering) and I have not seen places where Agile/Scrum has contributed positively. If so many people are getting Agile and SCRUM wrong (which is a supposedly simple methodology), so much that now has to be an Agile2 version, then let's assign a lot of the blame on the methodology, shall we?
Mind you, I've seen places that were not terrible using Scrum, but it not being terrible had more to do with decent people rather than the methodology. If anything, the framework was dragging the good into the mediocre, and the mediocre and bad stayed mediocre and bad, but with less time.
> Sorry to hear that you have been scammed :(
Nope. As a matter of fact, I think it's you who has been scammed OR actively trying to scam others.
> Nope. The manager isn't even there during the standup.
That's great! The manager is not in the standup! What big level of trust displayed here! If you trust them so much, why do you think it's needed to force them every day, at a specific time, in a specific format, to say what they are doing, and what they did yesterday? We used to do that in kindergarten. If you do trust your devs, you'd encourage them to sync however they want, whenever they want, and in the format that they want and omit sync moments if they see fit.
> Nope. It gives the team a chance to see what's coming to them in the future, and a feeling to guestimate the work needed
Nope. You got it very wrong, but I see where you are coming from, your way of thinking is common in the corporate world. You are considering developer teams like a highly paid black box, who take input from the $$$ people, and convert it to features. That's why you are using the passive voice: "what's coming to them", which shows me everything I needed to know about your way of thinking.
Imagine instead a situation in which the developers actually decide what to do as a team (based on usage stats, vision, own ideas, feedback from clients), without a glorified taskmaster force feeding it to them? In that way of thinking, nothing "comes to people", they control what they work on, their own priorities and their own tasks. Too radical, right?
> and a feeling to guestimate the work needed, so the less experienced people have a better chance to participate in the sprint planning.
Who are we guesstimating the work for? Instead of trying to guess how much time it takes, isn't it more productive to go in depth in each task and have members debate their approaches, and end up coming up with a solution? How is guessing how much it will take relevant to coming up with a good solution?
No, you and I both know that devs are made guessing because other people are afraid that the devs are playing ping pong all day, and want to have a deadline to hold them accountable to.
> The Scrum Master is not a role-job. It's a role of the day...
Great, and now open Linkedin and tell me how many full time Scrum Master positions there are. Thanks.
> If he is not doing his job, in answering the questions they have and unblocking their work, the team will leave him hanging dry for a sprint or two, and he is gone.
How can the least qualified person on the team answer any questions, about anything? It implies the devs don't know their users, they don't know the application, they can't be trusted to talk to clients, and they can't be trusted to make the right technical specifications. How is a PO better than a team of highly trained engineers as a decision maker and unblocker?
The role is just a remnant of the thinking that IT department are these unsightly people who work in the basement and shouldn't be seen/talked to, so we hire a suit to front them as a more eye pleasing alternative, a gatekeeper. Anything a PO can do, a team of devs can do better. Useless role!
> Wow. I see some major depression there. A sprint gives us the chance to tick a box every few weeks, instead of achieving nothing over years.
Interesting, it seems that you believe that if there are no mini-deadlines to put them in order, developers will simply do nothing, or go on a non-tangent for years, playing with languages and prototypes.
How about something that takes 3 weeks but can't be conveniently broken down into smaller chunks? Are you gonna be trembling with shame at the end of the sprint, because you didn't deliver "value"? What would the business say! Outrage!
> That is a role at your company? It's amazing what an Agile Coaching consultant can achieve by visiting 2-3 times a year
Luckily, no. But I've had Agile consultant visiting from time to time, they never contributed with anything but try to sell us their own flavor of Scrum or SAFe or some other garbage methodology. Mind you, this was at the time when half the teams were doing Scrum anyway. But the Agile consultant is like: no, that's not really Scrum, you have to "change minor detail, like length of sprint". And then the next snake oil salesman says the same, ad infinitum.
> Is Agile the holy grail of perfection? No.
That's mildly put. Agile is a steaming pile of trash. Yes.
> Is there anything else that gets even close? Hell no, but if you know a framework that works better let us know.
Yes, I do! If you want a name: "XP", but followed loosely and not religiously.
However, I just made an even better one on the spot, called "JBG" (Just be Good). It postulates the following tenets:
- Hire good people, retain them, build them up and trust them
- Fire/let go of bad people
- No non-technical managers, scrum masters or POs whatever for technical teams, they should consist only of developers
- Continuously improve all your stuff (tests/knowledge/processes/infra/code), in whatever shape/form/directions you want to and however and whenever you want to
I intend to write a book about it, a manifesto, and consult on it!
Have fun with your holy war, while the adults get work done.
The reason it wasn't communism, or even socialism at all, was the fact that *the workers did not own the means of production*. Whether or not you like the idea of communism or not, it's dishonest to call the totalitarian states of the 20th century "communist". They were authoritarian state-capitalists.
This leads me to believe that the author of this article maybe actually didn't understand agile as much as they thought they did.
Looking at the wikipedia I see "In 1949, Hungary was declared a communist People's Republic (People's Republic of Hungary). ... After Nagy had declared that Hungary was to leave the Warsaw Pact and become neutral, Soviet tanks and troops entered the country to crush the revolt. Fighting continued until mid November, leaving more than 3000 dead."
So arguably, he knows better about how it is living under that kind of regime than most of people.
Lenin Stalin and Mao were some of the best read scholars of their era who made genuine efforts to make communism happen.
They couldn't, not because they did not understand communism, but because communism didn't understand the world it was trying to be a solution for.
Humans are hedonistic and insecure beings for whom status games lie at the core of their existence. In the absence of inequality, there are no humans. For the potential difference is what makes sure the blood, sweat and tears flow in a certain direction.
_____
There in lies a great equivalence between fans of communism and agile.
You cannot create a productivity system for knowledge work if you do not understand knowledge work.
Agile starts with trying to solve a problem that it assumes exists, without ever questioning if its central assumptions have any validity at all.