I recently tried using some parts of scrum with my team at Microsoft. We're a development team in test and tend to have a lot of small, independent projects rather than one larger integrated one. To make matters worse, we work with audio and video and there is a lot of specialized knowledge with each project. It is non-trivial to move one person to another task. As such, it is hard to implement scrum as described in the canon. There is no clear feature backlog and there is no obvious way to define the results of a sprint for the group. I always wanted to try scrum but couldn't come up with a good way to do it. Over the past month or two, I tried to approaches. I'll go into more detail about them in future posts but here are the highlights.
We went through two phases of work recently. One was fixing bugs and the other was working on new applications. Each has a different work flow. Fixing bugs is more fungible, short, and discrete. Working on new applications is more specialized, the work items longer, and it is less obviously discrete. For each, I had the team meet once a day for 15 minutes to discuss their status. It worked better in some situations than in others. When the work items were longer, the meetings often seemed redundant from day to day. When the work items were short, it felt more natural to meet daily.
Our first attempt at using scrum came during what we call a bug smash. That is a time when we focus solely
ReplyDeleteIt occurs to me that some of those reading this blog will not be familiar with Scrum. Before I go into
ReplyDeleteA year and a half ago I talked about how I was running scrum meetings with my team. Since then, we've
ReplyDeleteA year and a half ago I talked about how I was running scrum meetings with my team. Since then, we've
ReplyDelete