Scrum – Lessons Learnt #1
Friday, October 14, 2005 – 10:53 AMWe had an additional chicken at the VSTO Frameworks Team Daily Scrum on Wednesday. Bernie, one of the Microsoft Engineering Excellence guys came over to see how we were doing. He’s been using Scrum for a while and had some great feedback. I thought I’d share it here…
Don’t use the standing meeting for gathering burndown data.
Standing meetings are for answering the questions like; What did I do since the last meeting? What am I going to try to do before the next meeting? What is blocking me for getting things done? Or, to put it more succinctly… “How am I doing, how it effects the rest of you and how I need help”
It’s very tempting to end up asking “How many hours do you have remaining on your task(s)?” I was doing this because, well, I was trying to keep the sprint spreadsheet upto date for the Team. I thought I was doing them a favor.
There are certain side effects to this…
- As a team member I was getting less out of the meeting because my focus was on some (stupid) spreadsheet and not on listening 100% to the other team members and helping them.
- I have really short hair so I hadn’t started to notice how pointy it was becoming. Yes, really. By collecting data I was putting myself in the role of the “how much longer is it going to take” manager, not a facilitator.
- In general this is a bad question to ask anyway, it makes people defensive. A large part of collecting burndown data is to give the Team predictability internally. So have them generate the data internally not report it. Then there’s less chance of anyone assessing individuals on their ability to meet the estimates they reported – which is exactly what you should be trying to avoid. (Kudos to one of the management chickens is the room who said he had no intention of doing any such assessments).
- It’s hard to use a laptop while standing, and it’s a standing meeting right?
So we’re going to move to having the team update the spreadsheet (which lives on a SharePoint Server) outside of the meeting. The only time “hours” will come up is to remind people to update their hours in the spreadsheet each day. We tried this yesterday and it certainly made the ScrumMaster (me) feel better.
Your Daily Scrum is going too long? Create a backlog!
We only really meet once a day as a team so it’s tempting to let productive discussions take place in the Daily Scrum. Sometimes this might be completely fine, if they’re brief and don’t break you out of the time box. If you’re discussing something that effects the whole team then nobody is wasting their time either. However, it’s hard to draw the line. Time boxing helps keep everything on track and prevents the team thrashing over issues.
Bernie’s solution was to create a backlog in the Scrum and keep the standing meeting time boxed to 15 minutes. At the end of the timebox you can have a followup meeting to discuss additional small items or you can schedule a full meeting for larger ones. That way people who don’t feel they’re needed can go do something else more productive.
We’ll be trying this for the second half of the Sprint and I’ll let you know how we get on.
Welcome to my blog on software development and probably a whole lot more.
Sorry, comments for this entry are closed at this time.