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:
Along the way, we did things wrong. We learned from our mistakes. Here is at least some of that knowledge:
- What did I do since last time?
- What will I be doing next?
- Is there anything blocking my progress?
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.
No hay comentarios.:
Publicar un comentario