17 likes
·
27.8K reads
8 comments
I'm 99.9% with you. I'm no fan of Scrum, but I think it's a bit misleading to bash it for the number of man-hours that the meetings (events) account for. The bigger issue for me is that the focus is on learning the rules of Scrum, not on putting in place all the minimum prerequisites that you correctly point out. I will share your article widely - fantastic!
I appreciate your thoughts, Richard. To be honest I was in 2 minds about the meeting math point, but I wanted to try and demonstrate how corporate agile can lead to inefficiency. I agree with you that the main problem is strict adherence to process - if having those team meetings do enough good for the team, it makes sense to keep them.
I wrote about what's wrong with agile here: ramijames.com/thoughts/the-work-structure-s..
Tldr: too much process is being rammed down dev's throats as a way to create visibility and accountability, instead of managers understanding that devs need autonomy to be creative and innovative.
The point of agile is.. to be agile. You want to be able to change stuff on the fly, make mistakes, shift direction, etc. Too much process makes that impossible.
This is very insightful Daniel Rothmann! It's often easy to do these practices because "things have always been that way" but looking from a different perspective helps to identify parts that needs improvement and try new processes!
Super banner for the Article How did you created it?
Thank you. I've created the visuals using Midjourney with a bit of prompting, trial and error to get something that looked consistent.
great!
Thank you for sharing
Really good write up... I think the most annoying thing about "corporate agile" as you put it (which I've unfortunately worked with a few times), is that it adds unnecessary layers of bureaucracy which doesn't seem to contribute at all to the final goal. I've even seen it as a way to prevent work from getting done, by saying things like "we can't do that many story points in a sprint". Then that work ultimately expands to take up the whole sprint, even if it shouldn't (as per Parkinson's principle).
Nothing drains my soul more than a discussion on whether a story should be a task or epic in Jira, or getting engineers to go away and spend 2 hours by themselves assigning story points.