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.
http://blogs.msdn.com/b/steverowe/archive/2005/12/30/experimenting-with-scrum.aspx
No hay comentarios.:
Publicar un comentario