Reinvigorating Daily Scrums
On at least one of our Scrum projects the daily Scrums aren’t popular with the developers on the team. My best guess is that they need to adjust their format a bit. Typically the developers just read off the spreadsheet numbers on their tasks:
OK, I did 34 and 36, and take 2 hours off 37. Today, I'm working on the JSF page for feature X.
They were of the opinion that maybe they only needed one or two Scrums per week. My top of the head suggestion was maybe they needed to adjust how they ran the Scrums. Perhaps trying to focus more on just finished tasks and stop worrying so much about exact hours. The point of the Scrums are to sync up the team and share information, not feel like drudgery.
Ed Gibbs @ June 5, 2006
Have you tried making it more physically involving? Instead of “reporting”, have people actually doing the planning/tracking. See http://silkandspinach.net/blog/2005/02/keep_the_story.html and http://silkandspinach.net/blog/2006/05/reporting_durin.html for some ideas…
I’d have to agree I favor the big physical charts as well. This team has just gotten attached to the Sprint backlog spreadsheets. At first the strict reporting was to get everyone used to reporting on small increments. Now that the team has gotten the basics down it’s seeming more like drudgery to them.
Something I learned from a Mike Cohn posting is that Daily Scrums are more about commitment than updating status. On my current team, we decided to focus only on obstacles and sharing commitment. The story board shows status.
Also, I’ve updated my patterns paper on daily stand-up meetings that covers all this sort of stuff:
http://hillside.net:9000/collection/browse_submission.ssp?identification=plop2006-jyip0
Our approach to scrum is pretty informal, but I’ve found that the important thing is not so much what each person did - we can see this in our tracking system. Instead, finding out if there are any problems the individual developers need help with is my focus as a scrummaster- from “I need permission to add a parmeter to this function in our core framework” to “my monitor is flickering and driving me bats” to “can you track down the user? he never returns my calls.”
Our approach to scrum is pretty informal, but I’ve found that the important thing is not so much what each person did - we can see this in our tracking system. Instead, finding out if there are any problems the individual developers need help with is my focus as a scrummaster- from “I need permission to add a parmeter to this function in our core framework” to “my monitor is flickering and driving me bats” to “can you track down the user? he never returns my calls.”
I like the idea of focusing mainly on impediments, but I have noticed that after doing Scrum for a while a lot of developers stop mentioning impediments unless it’s a large impediment. Not sure the best way to drag the information out of them.