pushed that 6S system on us as well claiming that because it was JapCrap it would somehow stop our company from dying.
Kanban originated in manufacturing, and it was one of the ways they became hyper-efficient in the 1980s to compete with the West. It came over to the US through car manufacturing. At least at the start, it was a great way to keep track of just-in-time inventory and factories... but just like Agile, it gets shoehorned into places it doesn't help. And of course managers will add management bloat on top of anything.
but you're not supposed to respond in "days", you're supposed to reply in "story points." the way this is done is through "planning poker"
This is a classic example of a terrible big system that started with a small good idea. In theory, giving an hours/days estimate will never be exact; software dev is just too complex for pinpoint accuracy. So you're supposed to measure in abstract points that compare relative levels of effort, not total effort. A 3 pt story is just slightly bigger than a 2 pt story, a 13 pt story takes nearly three times as long as a 5 pt story, etc. The Fibonacci numbering intentionally forces uneven comparisons, so you can never say 13 is
exactly 3x5, etc. It's almost a vibes-based management style for schedules.
In reality, once you quantify something, managers will get super anal about the numbers. If you delivered fewer story points this sprint, pointy haired bosses can look at a dashboard and say "HUURRRRRRRR NUMBER GO DOWN! GO DOWN IS BAD!" They will demand a steady burn rate (I will stab the next motherfucker who uses that term) instead of the natural, unsteady feature delivery inherent to projects. It gets even worse if you're being monitored directly by a paying client.
however, since every team has a different velocity and different meaning of what a story point is, that means that all this estimating is context free. like as a naive outsider, the reason i would estimate something is so i could figure out how long it is going to take to do, and when it is going to be ready. the reality in software is that we don't know, and that making guesses is useless.
Good managers realize this, and manage accordingly. Bad managers don't, and demand predictability. Agile is the compromise between the two, and like all compromises, it makes nobody happy.
Part of the problem is Agile was originally designed to not give a fuck about outside perception, it was supposed to be internal to the team. Even though an outside "product owner" exists, they are brought in and
made part of the team. But if you tell external management or bean counters "fuck you, we deliver when ready", they will chimp out. Half or more of modern Agile's bullshit is a compromise with external parties who don't trust devs to deliver on time or under budget.
Which answers the question:
How much does the agile framework contribute to the current enshitification we are experiencing as a society?
Agile is a symptom of enshitification, not a cause. If your team looked more like 1970s Bell Labs, 1980s MIT, or 1990s garage startups, nobody would dare question their velocity or hobble them with meetings. Agile is a harness non-technical people put on teams they think are measurable and controllable.
Managers would
love to use something more draconian and quantifiable than Agile, but it's the corporate compromise currently in place.
The real funny part is in the retros, "lets vote on the confidence that we can get this done," "why did you vote this low?" You know why, bitch.
