Our first attempt at using scrum came during what we call a bug smash. That is a time when we focus solely on fixing bugs. No work is being done on new features. This seemed like a logical time to implement scrum meetings. I chose to meet once a day for 15 minutes. We met at around 11:30 each morning. I chose the middle of the day so that everyone could attend and maintain their same schedules. Each meeting I would have our bug database open. On my white board I tracked the number of bugs we had fixed in the previous 24 hours as well as the number of outstanding bugs. When people arrived, we would go around the room and everyone would talk about what bug(s) they were actively working on and what they expected to fix that day. If someone had no bugs left in their queue, we would reassign them bugs from someone else’s queue.
There were at least three good things that came out of these meetings. First, it gave me a good opportunity to gauge our progress. Each day I saw how we were progressing. Admittedly, I could have done this myself by spending a few minutes in the bug database, but this was a forcing factor. I also was able to hear how people were doing. When they were stuck on a bug, I knew about it quickly. Second, it allowed the team to see where we stood. They knew where we stood as a group with the numbers on my white board. They also knew how their teammates were doing. Hard work is contagious. The third, and mostly unexpected, benefit was the cross-pollination that took place. One team member would say they were working on a bug and someone else would speak up with suggestions for solutions or places they might look for code doing something similar. We ended up being much more efficient as a team because of these short meetings.
For this bug-fixing stage of the product, small, short meetings on a daily basis proved very useful. It is not fully implementing scrum and not even really fully implementing the scrum meeting portion of scrum, but it was useful.