The Case for Agile 2 (Agile is deeply broken)(agile2.net)
agile2.net
The Case for Agile 2 (Agile is deeply broken)
https://agile2.net/how-we-got-here/the-case-for-agile-2/
8 comments
Leadership being unable to avoid attaching MBA measurements to unicorn points was really the fundamental flaw of agile. It's what bankrupts the estimation and execution and cooperation in a team, because it becomes a game of grabbing high value low effort tickets and inflating them so "velocity" increases.
There are many other issues with Agile. I certainly don't want to defend it. The dogmatic release cycle, the no-tickets-crossing-sprints. Standup where everyone talks.
Waterfall is broken, but the ONE THING it had was the ability to cook on things over long hauls, and actually research/prototype/experiment. Something that iterative Agile should in theory make achievable, but you cannot when management is scrutinizing every ticket for "productivity". Prototypes and research are waste to almost all middle management, they want features and bling to get them promoted.
The Wire had it: "juking the stats". Or alternatively a quantum-esque principle that any efficiency metric becomes useless once management observes it/uses it to judge workers.
I would routinely have 8 point tickets that simply overflowed across 3-5 sprints. I didn't bother breaking them down, because it was a waste of time. The ticket described the unit of work from the proper level of detail.
Retrospectives were crap because everyone had to say ... SOMETHING. It couldn't simply be a meeting where we said "eh, good enough for now". Retrospectives generally danced around the real problems that we had no real control over: dumb dictated schedules, management intrusion, lack of resources to handle support tickets and other unplanned stuff that would distract you.
Agile also typically came with some fantasy of "everyone works on everything", complete and utter baloney.
Finally, Agile really really incentivizes getting the least good solution to a problem. There was no incentive to clean things up, write a medium-term rather than a hack (YAGNI is not always true, people).
But what Agile had correct in the abstract was the notion of iterating to a solution, rather than a waterfall. Did it have to be in two week (or shudder, one week) cycles? No, unless you are doing CSS/UI button placement/font selection bikeshedding. But maybe working towards 2-5 week milestones and check-ins with stakeholders? Oh yeah, that would be about right.
There are many other issues with Agile. I certainly don't want to defend it. The dogmatic release cycle, the no-tickets-crossing-sprints. Standup where everyone talks.
Waterfall is broken, but the ONE THING it had was the ability to cook on things over long hauls, and actually research/prototype/experiment. Something that iterative Agile should in theory make achievable, but you cannot when management is scrutinizing every ticket for "productivity". Prototypes and research are waste to almost all middle management, they want features and bling to get them promoted.
The Wire had it: "juking the stats". Or alternatively a quantum-esque principle that any efficiency metric becomes useless once management observes it/uses it to judge workers.
I would routinely have 8 point tickets that simply overflowed across 3-5 sprints. I didn't bother breaking them down, because it was a waste of time. The ticket described the unit of work from the proper level of detail.
Retrospectives were crap because everyone had to say ... SOMETHING. It couldn't simply be a meeting where we said "eh, good enough for now". Retrospectives generally danced around the real problems that we had no real control over: dumb dictated schedules, management intrusion, lack of resources to handle support tickets and other unplanned stuff that would distract you.
Agile also typically came with some fantasy of "everyone works on everything", complete and utter baloney.
Finally, Agile really really incentivizes getting the least good solution to a problem. There was no incentive to clean things up, write a medium-term rather than a hack (YAGNI is not always true, people).
But what Agile had correct in the abstract was the notion of iterating to a solution, rather than a waterfall. Did it have to be in two week (or shudder, one week) cycles? No, unless you are doing CSS/UI button placement/font selection bikeshedding. But maybe working towards 2-5 week milestones and check-ins with stakeholders? Oh yeah, that would be about right.
I found it super funny that Agile started as an essay that basically boiled down to:
- Don’t create a bunch of process; just talk to each other
- Seriously stop using tech to avoid talking to each other
- For the love of god just talk to each other and show off what you are trying to build.
Then we took that and immediately built a bunch of process, certifications, and software to enable us to pretend to do this.
- Don’t create a bunch of process; just talk to each other
- Seriously stop using tech to avoid talking to each other
- For the love of god just talk to each other and show off what you are trying to build.
Then we took that and immediately built a bunch of process, certifications, and software to enable us to pretend to do this.
This appears to be a lot of words collected by committee, and about a lot of random things. Not clear what any of it has to do with agility, or why original agile principles wouldn't apply.
It talks about leadership and various stakeholders, but that is one of issues that agile addressed pretty well imho: get people to say what they want next, leave the team alone for a time so they can implement that without interference, then demo a working solution for feedback from stakeholders.
If an org can't even do that, there's issues beyond development process that this "Agile 2" doesn't seem to address either.
It talks about leadership and various stakeholders, but that is one of issues that agile addressed pretty well imho: get people to say what they want next, leave the team alone for a time so they can implement that without interference, then demo a working solution for feedback from stakeholders.
If an org can't even do that, there's issues beyond development process that this "Agile 2" doesn't seem to address either.
We're finding Shape Up good. The ebook isn't long, it's worth reading. https://basecamp.com/shapeup
I look forward to another 20 years of bikeshedding over what this manifesto actually means over doing real work.
[deleted]
Agile is broken? Or the fact that we put the smartest people in positions in which they have no say, and anybody else we give them all the power (scrum masters, product owners...).
> "Leadership is the most important thing of all in an organization: with good leadership, the initial methodology will not matter in the long run because it will be adjusted as needed; conversely, with bad leadership, the best methodology in the world will fail."
Yes, that's one of the bigger reasons Agile "1" tends to fail. This Agile 2 doesn't fix any of the problems that companies have in properly following the original agile manifesto.
> "The original Agile Manifesto was created by a collection of middle-aged Western culture guys (like this author) and all from similar cultural backgrounds. For Agile 2, we assembled a global team of 15 people, with skills and experience in program management, leadership, human resources, product design, engineering, data science, and of course Agile and DevOps."
Also found this sentence (among others) completely unnecessary.