> 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.
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?
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.
Our 15 minute standups were about an hour, sometimes longer. The project manager aka scrum master spent at least 80% of those minutes talking. They were scheduled for 11:30am, right when everyone was either wanting to go to lunch, or for people not taking lunch probably the most productive middle part of the day. For those who went to lunch afterward, they never got to start before 12:30pm, and were out to at least 1:30pm. So it sort of wrecked the start of the afternoon too. Not that it didn't wreck the lead-up either, because if you have that crap looming over you at 10:45am you sort of shut down any important thinking you need to do... best not get caught up in what you are doing, because if you're 1 minute late for the standup, there's hell to pay.
But, what little progress there was, was easily measured. That seems to be the important part.
There may be a mythical "scrum" out there somewhere, but I and no one I've ever known has seen it. As much as I love a No True Scotsman fallacy, if this is the only thing people have ever seen and have ever attached the label "scrum" to...
Well you don't know me but I am not a scrum master and I was on a team that had a great experience with it and are all still friends years after we all went to other jobs. It was the great experience of my life.
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.
That argument can be used either way around so it's fairly useless.
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.
> 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?
Oh, that's very easy. So much so, I wonder exactly how you managed to perform everything required for a planning or review in the time you give. 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.
Combine that with daily standup, a once-weekly meeting to just hang out for 30m or so, check-in with manager, team meetings (meetings for everyone under a particular manager), multiple demos per week from various areas of the company (technically optional, I don't go to most of them), all-staff meetings, ad-hoc meetings with people from other areas of the company for specific work when they're a dependency or stakeholder, etc.
Sprint planning is typically 4 hours [1]. I think there are further reasonable quibbles to be made that would revise that 7% number up to a reasonable 13% or 18%.
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
"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."
At my previous job, the "daily stand up" never lasted less than 30min, and often times went to 2 hours. Also, I didn't just have one "daily stand up" but two! One with multiple teams, and one with just our team because our manager really wanted to silo our work and ignore as much as possible other teams (especially QA for some bizarre reason).
Yes, we weren't doing "scrum" right, but like communism, no one does it right.
We manage short standups most of the time - why didn't you tell the manager to shut down after 15 minutes? All these agile processes require the team to take some responsibility and have some courage.
First, there was major miscommunication on the part of the new management [1] and who I thought was my manager wasn't [2]. Second, I was raising the alarm that the "agile and scrum" methods weren't working, and got it raised to a VP of the company [3]. He was let go. Did I cause him to be fired? I don't know. All I know, the new VP just said "that's a shame" when I brought up my points. I knew then, it was time to go.
[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.
No, it was more like before they pushed "Enterprise Agile with a side of scrum", the team I was on, for 10 years, produced code on time, with very few bugs and only two regressions to production (caught during deployment). Afterwards (bought out, new management), we kept missing our deadlines, bugs proliferated, and deployments became nightmares. The meetings were the least of the issues, but they weren't helping any.
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?