Dear Readers –
We continue to use Scrum on our project, and we’re now finishing our third sprint (numbered sprint 4 to match up with pre-Scrum milestone numbering).
It’s been a stressful sprint. We had a bunch of very hard changes which took much longer than we expected, and this week it became clear that not all of our sprint goals would be completed. Worse yet, we realized that we really had three written sprint goals plus an unwritten sprint goal – four goals for a Scrum team with 3.5 pigs!
That was one big lesson for me that we’ll need to apply to the next sprint: pick one or two themes as your sprint goal, and leave the rest as sprint backlog items that could be cut in a pinch. And don’t have any unwritten sprint goals!
As it was, this week my Program Manager counterparts were running around screaming that we had to terminate the sprint if all the moons didn’t align for our project. Some of the PM’s were blaming the dev team for not deliving enough, some of the devs were blaming the PM’s for engaging in schedule bullying (pressuring them to reduce work estimates at planning time), and everyone was stressed out. I had a good time in
Fortunately we managed to look coolly at the situation, we agreed on a core subset of the sprint goals (written and unwritten) that would decide between sprint being aborted or not, and moved ahead. The key blocking piece which was needed for progress on two other pieces was delivered, and it looks like we’re now headed for a normal (and fairly successful) sprint completion. However, the stress that this sprint imposed on everyone involved was too high.
Next sprint we’re going to make sure we have more focused goals, less ambitious plans (perhaps via more explicit schedule buffers), and a better way of tracking and costing one of our messier tasks (changing the way a tree is built and making sure nothing subtly broke). Of course, that’s what we said we were going to do before this sprint, but I think the experience of sprint 4 will motivate us all to approach sprint 5 in a different way.
In my mind, the great strength of Scrum is not that it necessarily makes hard & messy projects easier, but it makes the pressures and implicit problems on a project much more visible and open. And when issues are visible and open you have a much better chance of working through them in a constructive way.
Over and out!