I do not understand how this is possible.
* Sprint planning: 2 hours
* Sprint review: 1 hour
* Sprint retro: 1 hour
* Daily stand-up: 15min / day
On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%.
What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?
Yes, we weren't doing "scrum" right, but like communism, no one does it right.
[1] The silliness didn't start until new management took over.
[2] The term "team lead" meant "manager". I didn't get the memo.
[3] I was regularly talking to him at least once a week. He didn't want me to leave the company and to give him time.
* pre-planning - 30m
* planning - 30m
* refinement - 90m
* ultra refinement - 90m
* retro - 60m
It's laughable.
Week 1: One whole day for demo, retro, planning, commitment. But because the scrum master had to "build" a sprint and couldn't do that without knowing the size of tickets, there were two morning meetings every week to "analyse" tickets. So two mornings for "analysis" to produce point estimates for tickets.
Week 2: Also two mornings for "analysis".
So 3 days out of the 10 day sprint, so 30% time spent on Scrum.
Plus standups, they were at 10am so 9am-10am nobody did anything (as judged by the number of PRs and comments and Slack activity) so that's an hour plus the time for standup every single day, so I guess the work day started 10:30am on those days which weren't scrum days or scrum mornings.
Plus the scrum "analysis" meetings were in the morning as it was generally accepted everyone was too tired in the afternoon to to those meetings. So what that actually meant imho was that programming was a low-importance activity that could be done when tired, after the actual work of Scrum had been completed.
Maybe that's insanity, I mean I certainly thought so, but these things do happen.
But, what little progress there was, was easily measured. That seems to be the important part.
Lunatics run this asylum.
In reality we don't have good software development because people at some level or another don't want to do the things that make it possible. They're always going to pretend they care but do what suits them.
It can be from the most basic thing: the customer doesn't want to pay what it really costs to get something good but can be made to pay for something that's going to turn out to be crap in the end.
If you're confessing that it's contrary to human nature and/or the engineering thought process, then I humbly accept your concession in this debate.
Then that is what scrum is.
I know how it worked and why every team I've been on since has not been able to make it work and it all boils down to: 1) internal sabotage - an influential developer does everything they can to shit on it. 2) Management interference - developers could not change the things we needed to change to make it fit our circumstances.
Oh, that's very easy. Business meetings can take more than expected in the best of cases, and the various dysfunctions inherent in scrum only add to that.
Here's a fairly obvious example - scrum encourages you to have a lot of management. At minimum a team needs a product owner, a team lead and a scrum master (and if you merge those positions you aren't "doing scrum properly"). Because there are so many managers, each is under pressure to prove they add value. How do they prove that? By providing valuable input in the various ceremonies scrum requires. Hours of it.
And sometimes they add so much value it can't be contained in the normal flow of scrum meetings (or rather, the meetings can't be contained in the course of a work day), so more meetings have to be created.
The 13% takes into account the time tax of context switching. 18% if we consider only (at best) 6 hours per day and meetings are taking away from that high productivity time (which is to say a greater proportion of time is spent around the coffee maker and not coding)
To go into detail, there is a tax to every meeting. With 13 scrum meetings this adds up fast. For me, as a remote worker, I stop everything 5 minutes before or else (for example) 1:57 is going to suddenly turn into 2:03 and then I'm late. Recovering from a meeting takes me about 10 minutes (plenty of resources state it takes 25 minutes to get back into a flow state once interrupted).
Thus, for me, the meeting tax of scrum meetings alone is 13*15 = 195 minutes. Further, there is a conflict as projects have their own required meetings (if the scrum meetings are the only meetings, then seemingly the team is just talking once a day and then not again - that sounds bad! So yeah, there are other meetings too).
Further, not all 80 hours are equal. Software development is a highly creative field, it's not an assembly line with interchangeable parts. If you have your developers in office for 90 hours instead of 80 you're not going to get 10% more on your story point velocity. Similar for 70 hours vs 80, eventually there is a point of diminishing returns.
By measures of how long I can pair program with someone, 5 hours is a pretty upper limit on how long I can stay in a high productivity state for one day. Time spent in meetings can take away from that high productivity.
Let's say a person can generously be in a high productivity state for 6 hours per day and that meetings take away from that time, then we are very reasonably at 10.75/60 => ~18%*
*I'll emphasizes we are talking scrum meetings only, and still not even taking into account prep time for the scrum meetings
[1] https://resources.scrumalliance.org/Article/scrum-events
"The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint."
It is a bit sad, but that is my experience as well. I had one good manager in my 12 years experience. I had to work around the rest.
Nobody usually wants this.
For developers scrum is actually quite nice. The main success metric is predictability, i.e. the team is held accountable for delivering the sprint successfully. Which means you're supposed to be left alone while the sprint is ongoing.
Some bug? Pfft, if not critical, will maybe take it next sprint.
Finance needs a new report, pronto? Sure, let's talk about business value for priorization. And earliest next sprint anyway.
CEO has a crazy idea that he wants somebody to pull off? Sure, but please talk to Product.
What do you mean, you need more story points delivered per sprint?
The main issue is there are actually people that thrive in this kind of bureaucrazy. I've seen a number of 20-something POs burning themselves over these shitty processes.
And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.
Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.