I’ve never not been a developer in a „scrum“ team. And each org butchers the framework in one way or another. Dedicated scrum master? Meh, let the PO do it. Let’s estimate stories based on the time it takes to complete them and eventually measure our velocity based on days worked on a ticket (and pat each other on the back when a sprint without holidays finished). Let’s plan the next 12 months like this based on loose terms and draw some deadlines in the sand - which we will absolutely insist on later but worry not it’s still scrum because you guys do the scrum related meetings. Let’s have a status report during dailies because instead of fostering collaboration middle management would like to know whether they can update their weekly progress PowerPoint mid sprint.
Let’s document every minute on every ticket, meeting or 2 paragraph chat message to help someone from QA because transparency. Let’s have a disjoint backend, frontend and testing subteam on the same scrum team and discourage cross functionality because of efficiency but still have them all sit in the same refinements twiddling thumbs. Let’s strip the PO of every ounce of decision power so they become an imperfect messenger of non-agile middle and upper management. Let’s have plannings and refinements together. Let’s do a mid-sprint planning for all the production bugs which we will not estimate. Let’s have 5 backlogs - product, bugs, technical debt, experimental and misc - and let’s ignore the technical debt one.
Let’s not listen to developer feedback and rather tell them which tools to use for the job.
Let‘s never document anything technical even if it is super obscure but incredibly important because we should rather work on features that increase revenue in the short term. Let‘s never pair - that’s twice the time booked on one ticket and we can’t have that. Let’s have a pre and post refinement. Let’s write todos at the end of a retrospective which nobody will ever be assigned to or complete.
I've actually had to read the "scrum manifesto" when I did an internship as a junior developer.
I realized then that absolutely no one there who was "hyped" about scrum and agile really knew what was in there. And it was maybe at most 20 pages?!
I didn't really have a big epiphany after reading that but certainly I could act like all of that matters and "play the scrum game" if it made my manager happy.
Project management processes and frameworks like that seem so pop sciency or assumption-based to me.
It does seem kind of convenient actually, that the manager doesn't have to tell the workers "work more quickly to generate me more profits" and can instead just point to the currently trending buzzwordy practice. Or more likely the manager even genuinely deluded him/herself into thinking it really makes a difference.
Unfortunately I think a lot of developers will see this as what "agile" actually means to them because it has been perverted so much.
Some companies have financial incentives to treat software as an asset - like a building that you build once and never change. So change is discouraged. You can make something once but fixing it is very much frowned upon as the cost has to go against the operational expenses budget. You can see how accountants think like this and how deeply it makes sense to them and yet how comically stupid it is.
I think the problem is everything is against agile development in a company which is not agile from the top and whose customers are not agile and which puts ridiculous financial reasons in front of those relating to the functioning of its products.
One of the things I absolutely love about my current job is not having to use agile. I didn't realize what a massive waste of time it was at my last two jobs because I'd never experienced not having to use it. If I switch jobs in the future, I'll definitely try and push management/product to try not using it.
> provided a detailed plan is in place to respond to the change, and it is followed precisely
I worked for a company that went through an ISO 9001 process certification formalizing our Agile process. One of the charts detailed the process for changing the process. Art imitates life imitates art.
BCG uses the term ADU - Agile Delivery Units - instead of resources. That sounds directly like a term from the handbook of the ministry of truth.