I have 4 tickets in this 2 week sprint. I lose a couple of productive days for scrum ceremonies and meetings. The last 2 or 3 days must be spent scrambling for code reviews and QA sign off. With the time that’s left I can make the software as good as I want.
That's a terrible bastardization of agile. Agile and related practices aren't about delivering increased volume of work but just about making the team more responsive to changes. If you feel like you're always rushing to finish a sprint either your manager is pushing on the gas to squeeze past a deadline (a good sign of bad management) or you're in over your head and not performing at the level expected of you. In either case a manager should see this and work out a solution that lowers your workload.
"Agile," as advanced by management and coaches peddling Scrum and various "methodologies," is exactly like this in practice. It's micromanagement in disguise.
You can argue that's, "not true Agile," but then... what is? The process being forced upon developers the world over or the ideal version you have in mind?
I agree, as described, it generally leads folks to burnout. And anecdotally it seems most organizations are fine with that.
On the one hand, yes, at this point "that's not true Agile" is starting to sound like a no true Scotsman fallacy.
On the other hand, the way the term "agile" is used now really has no relation to anything in the agile manifesto.
And this is in part due to ignorance (people adopting agile trusting that their "scrum certified" trainers know what agile is instead of just ... reading the short manifesto), in part due to how (intentionally) vague agile is, and in part due to complacency of the people who _do_ know what agile is not pushing back more against the idiocy.
I don't think you can blame people who happen to have actually some clue as to what agile was supposed to be repeatedly complain that the crap which most organisations implement and call "agile" has nothing to do with agile.
I like terrible analogies so here is one:
It's akin to finding a paint bucket in the building supply store marked "red paint" and finding it filled with blue paint, and then when you go to the store to complain, they say: "but this _is_ red paint, you will find the same colour paint in these buckets in _every_ store". Then when you do a bit of research you realise that the only reason this happened is because people who really liked to paint walls blue heard about "the red paint craze" and started calling blue pain red to avoid having to change the colour of their walls.
> On the one hand, yes, at this point "that's not true Agile" is starting to sound like a no true Scotsman fallacy.
Always has been. There's nothing wrong with the manifesto as some food for thought. But the moment people started calling their development process "agile" we were all fucked. It became a brand.
The core con of agile is that there is something under the covers as long as we push beyond doing it wrong.
There is no there there.
The manifesto says: Along all the dimensions that exist in software development, here are four dimensions where the common practice in 2001 are wrong. Any other meaning is invented while interpreting scripture.
For what it's worth, the "Twelve Principles" document [0] is both more explicit and constraining. As you say, though, it is a framework for change (a goal to be incrementally approached), not a brand.
Because you just haven't seen a correct implementation of AGILE.
If we look at the AGILE Manifesto then we know for sure that there is no way this would ever be allowed if applied perfectly.
And humans excel at perfect implementations.
Begone with the naysayers that keep deriding our objectively pure implementation of AGILE.
Okay, okay, I can't anymore, its too much, I agree.
So how about we just fight fire with fire.
I propose a new religion named JOUST.
I don't have the energy or time to invent more than the name. Use AI to create the system.
Start amplifying the signal that JOUST is the new AGILE and soon, we will have a new word for micromanagement.
I have seen two distinct implementations of AGILE and neither has left me thinking that anything was gained.
I also have a deep resentment for the word sprint.
Sprint means go at the fastest possible pace, yet there is no downtime in between sprints?
Bad analogies are great.
Show me a cheetah that sprints 5 days a week for 9 hours a day with 2 days of "rest" in between.
When a group of people pick a manifesto and are empowered to work towards improving their own working conditions, it's great.
My comment has the flavour of a, "no true scotsman," situation but it's not necessarily, in my view, a matter of calling a spade a spade.
The problem is that the spirit of the manifesto is a socialist one which runs counter to how capital runs businesses. The manifesto says "we," meaning the developers doing the work, should prefer customer collaboration over negotiating contracts. However most developers in most companies do not have the power to enforce this preference. The executives, founders, and managers sign the contracts. The developers are hired to write the software. There is no negotiation: your team doesn't meet their deadlines people will start getting fired or the business will go under.
"Business people and developers must work together daily," they sure do. Every stand up, every morning, to tell the manager/lead what you did yesterday, what you got stuck on, what you're going to do today. "But that's not how it should be," well... again, what should it be? The manifesto isn't prescriptive about this. Agile-as-practiced is what we observe teams and companies doing out there. This is often how it's done.
Individuals and interactions over processes and tools? What part of agile-as-practiced isn't about processes and tools? Capitalists love processes and tools ever since they brought their own clocks and bells into their factories and started docking people's wages when they didn't show up for work on time. Planning poker, retrospective meetings, kanban boards... all processes and tools.
No businesses I've heard about or worked at have enabled developers to self-organize. This, again, would be anathema to how capitalists expect to run businesses.
The other problem with the manifesto is that it's starting to show it's age. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation," is a good way to ensure that your later maintainers have no idea how the software works anymore... and hasn't been true for decades: most of Linux and much OSS is developed by remote teams who've never met face to face. Writing is generally considered the best way to pass on information and it has been quite effective for a good portion of human civilization.
I don't think this has anything to do with capitalism.
We have carpenters under capitalism and the companies hiring them don't force them into stand-ups every morning with some guy who has never nailed two pieces of wood together who insists on following a rigid process of chopping up the work of framing a house into sprints, user stories and story points.
I actually don't work as a programmer anymore (instead as a security consultant) and suffer no micromanagement (in fact, almost no management at all). I think this is just a unique nonsense which has developed around the practice of programming.
Genuinely whether I am working on a project individually or as a team, myself and my teammates get complete freedom of how we go about doing our work as long as we uphold certain standards and produce certain deliverables. This definitely seems possible in the world of software development.
The certified coaches peddling Scaled Agile Framework (SAFe) certainly don't advance micromanagement or anything like that. I have been in their training sessions.
> Agile and related practices aren't about delivering increased volume of work but just about making the team more responsive to changes.
"Making the team more responsive to changes" so they can start "delivering increased volume of (often poorly specified, decided on the last minute outside of quarterly planning ceremonies because it will make the engineering middle manager look good to the CTO) work" has been my experience with agile everywhere I've done it.
Why would any publicly traded business pick a development model that _decreases_ the volume of changes?
Being "responsive to changes" has absolutely no relation with "volume of work".
Agile is about being responsive to changes. And yeah, the bad specifications are included. Anybody that makes it about volume of work is dishonest (but I do agree that's the norm).
We should not let dishonest people bastardize our language to the point we can't communicate. And the most obvious way to fight back is to call them on their lies.
(And yeah, it's implicit but it's very clear that agile is supposed to decrease the volume of work. You can't decide to optimize for something else and not suffer there.)
> Being "responsive to changes" has absolutely no relation with "volume of work"
To you and me, yes, that's a true statement. To the business, it's not. Being "responsive to change" means we're constantly polishing the turds the CTO-adjacent crowd has laid, and we do no service to ourselves by pretending otherwise, or trying to reclaim the language of "agile".
Well, what you work on has also absolutely no relation to how much work you do. Or with how responsive you are for changes.
You seem to have an emotional issue linking those concepts. They are all different things. But yeah, lying about what you do is harmful too. The top management not wanting to solve real problems or making real products is about as bad as any other kind of management failure.
> You seem to have an emotional issue linking those concepts.
Hey, I wanted to thank you for this comment. I was really tilted yesterday about adjacent issues and was inadvertently bringing that here. Your comment made me take a step back, look at what I was posting, and stop posting while I was emotional.
If you're scrambling at the end of an iteration to complete quality control tasks in order to accept user stories then you need to shift those left. Split the user stories into smaller chunks (as long as they still deliver value), have multiple team members work together on a single story to complete all the tasks (swarming), and write the automated test scripts in parallel with coding or even before (TDD). People sometimes try to tell me that this approach is impractical or won't work, and yet when I led Scrum teams and forced them to do it that way it produced good results and the team members were happier.
