Scrum Meetings for Test

A year and a half ago I talked about how I was running scrum meetings with my team.  Since then, we've refined the process but have consistently held scrums on a regular basis.  Note that I'm not running a full Scrum system with sprints and product backlogs and such but rather just adopting the scrum meetings from that system.  Currently we have a team of 8 test developers.  We meet twice a week for 1/2 hour.  The format is simple. We go around the room and each person answers three questions:

1. What did I do since last time?
2. What will I be doing next?
3. Is there anything blocking my progress?

Doing this helps me keep the pulse of the team and--more importantly--helps the team keep its own pulse.  It also encourages the team to act as a team.  It is easy in software to put yourself into a silo.  You have a task and you disappear into an office for a few weeks to get it done.  You might talk to your manager about it, but you don't talk to people outside your dependency list.  The disadvantage of this approach is that you don't get help from others.  In a scrum meeting, everyone learns what everyone else is doing.  If someone has experience in something someone else is struggling with, they offer their assistance.  In this way, the team starts supporting itself and the overall output increases.

Along the way, we did things wrong.  We learned from our mistakes.  Here is at least some of that knowledge:

• Scrum is disruptive.   Programming is a matter of building up a mental map of the problem and then writing down the solution.  Once someone has this map built up they can work efficiently.  Having to change to another function is akin to swapping out the pages of the map.  Trying to start back up again requires paging everything back in which is slow.  Unfortunately, the human backing store isn't always stable and some paged out data gets lost.

• Don't run scrum too often.   During a time where you are burning down bugs, meeting daily can be useful.  During the rest of the time, meeting daily is too often.  There isn't enough new to report and, worse, it tends to become disruptive.  Perhaps someone who has done daily scrum during the development phase can explain how this is avoided.

• Scrum can't be seen as judgmental.   I found that without some calibration, team members felt that they were being judged by their progress.  If they didn't have something new to report, they felt it would be held against them.  Because of this, they didn't want to show up.  The solution was making it very clear that scrum meetings were all about status.  Being open is much more important than the level of productivity any individual was able to demonstrate.  The purpose isn't to take notes for the next review.  Being explicit about this helped.

• Don't get bogged down in details.   The natural tendency of engineers when faced with a problem is to solve it.  This is good, but scrum isn't the place for solving problems.  It is the place for surfacing them.  Solutions should be derived outside the meeting.  Keep the meetings to their scheduled time limits.  Don't allow discussions to get into too many details.  Instead, take a note and have a followup discussion later.

Comments

• Anonymous
  August 13, 2007
  We have daily scrum meetings, and the way we keep them from being disruptive is to:  Keep them short (5 minutes total)  Hold them at the beginning of the day

• Anonymous
  August 13, 2007
  Kujo, how big is your team?  5 minutes seems like it would disappear really quickly if the team were very big.

• Anonymous
  August 13, 2007
  I have worked with a development team of 4 developers, 2 testers and 1 project manager, with daily Scrum meetings. We did the same thing as Kujo, hold them at the beginning of the day and keep them very short. They very rarely went over 10 minutes (often less than that); if there issues were brought up that needed more discussion they were written down and dealt with in a different meeting. I didn't find them disruptive at all; quite the contrary, they did help to deal with issues that weren't recognized as such at the beginning of the iteration, or that came from other groups we had to interact with. Less frequent meetings would probably prevented us from effectively reacting to change within an iteration.

• Anonymous
  April 21, 2009
  Having been a manager* for a while now, I’ve learned more about what it means and what changes it requires