I'm sure some people prefer to be force-fed instead of learning on their own, but self-organised schools as in the OP should at least be an option for people who know what they want.
I'm sure some people prefer to be force-fed instead of learning on their own, but self-organised schools as in the OP should at least be an option for people who know what they want.
Why are you having an eight hour Scrum meeting?
Isn't that the complete opposite of what a Scrum meeting is supposed to be? 15 minute max, standup meeting is a Scrum.
I guess our meta-problem is that Scrum was a buzzword-based requirement chosen by non-programmers, so we naturally have programmers subverting the process out of spite, lots of politics and distrust, and inexperienced folks managing the whole thing in a horribly broken JIRA installation (what else?).
As a result, our development team is _really_ far behind on a huge backlog of very fuzzy stories. If you realise in a meeting that you've misunderstood key requirements, there's no point going back to building the wrong thing after the time-box ends. You have to come up with a new plan, and at the same time you need to make it fit into the desired Scrum schedule, and don't break that burn-down chart or JIRA, ...
Of course, at that point it is not really a Scrum meeting anymore.
That's the first thing I'd scrap. Software to control the process doesn't help unless the team understands and wants the process, otherwise it's just an annoyance.
My path towards Scrum started after a pointless and long meeting. I found some coloured memo squares and some drawing pins, and cleared everything from an old noticeboard. (This is nicer than using post-it notes on a whiteboard.)
I copied out the tasks, making a rough go at splitting them into reasonably-sized things, and making my own estimates in days. I made "backlog", "this week" and "completed" columns.
The resulting mess showed that the project wasn't under control, which itself was valuable. The PM and the 'customer' were then able to ditch half the requirements, and the developers could concentrate on the highest priority tasks.
This wasn't Scrum, but it worked well, and led to buy-in from almost everyone that we should try Scrum.
(The most important things I missed on the first go: acceptance criteria and team estimation.)
15 minutes really should be an absolute max as in after 15 minutes everybody just leaves regardless of how late you started. In fact you should have no more than 50 minutes per 5-day week for scrums so that anything going over 10 minutes starts counting against the rest of the week. I call them roll-under minutes.
Too often the team gets too big or unnecessary meeting jockeys start attending and it all goes to hell.
Also, I would hope that you at least come out of the meeting with point values on all your stories for the next sprint and a defined sprint backlog. With each story having clear definable completion criteria and clear consensus around what the goal of the story is. If you are, that doesn't sound like a waste of time. If you aren't... back to your scrum master and their job.
If you're talking about the actually daily scrum meeting... get out of there as fast as you can. I've seem meetings go a few minutes long but that is 7 hours and 45 minutes too long. We get upset when our meetings are longer than 8 minutes for a 10 person team.
I still need to sit through a few dumb meetings before I can give feedback, though, and even then it doesn't always work.
holy cow, is that a real thing? I feel like that's a contradiction in terms. Our sprint meetings and daily standups have slowly decreased in length based on perceived utility, to the point where they are now just a message dump in slack.