I’m working on a project at the moment which is using SCRUM. So far I (and hopefully the team too) think it’s going well despite the occasional FUD that you hear about the place, sometimes this can be distracting but I keep telling myself that we’re getting a return from the process and those responsible for the FUD are just clinging to their safety raft (albeit one usually full of holes).
Taking on any new process, SCRUM or otherwise is a challenge and it’s this challenge together with the complexities of the project which makes days like today really engaging. I’m really tired and I feel more committed to the project than ever, but the odd thing is that today started with a failure.
Today was our Sprint Retrospective. I had to demonstrate the working software that we’d committed to in the last sprint and it failed – this was not as bad as it first may sound because there were clear reasons why the software was failing:
- Items on the sprint backlog were not well understood by the team (me in particular!).
- Project dependencies were not well understood prior to the Sprint planning taking place, which meant we’ve learnt many of these dependencies during the sprint and had to adapt to these
- We need to bring testing into the sprint
- We need to be careful when adding new items to the backlog during the sprint - asking the question “can the sprint deliver the software as committed to without this item?” is a useful way to eliminate unnecessary items creeping onto the backlog
- ‘Work in progress’ occured during the sprint and remained once the sprint was complete.
However there were many positives from the sprint too, we came close to achieving the sprint goal (close but no cigar), we’re working well as a team and we all have a role to play in the process and the projects success. We’re getting better at estimation, at examining the items on the backlog, at adapting to change, at working toward a defined goal and these changes and improvements are occurring quickly. Today was an early failure, and not one that was exposed beyond the product manager (although IMO its not necessarily a bad thing for a client to see these failures too, especially if they’re actively involved in the SCRUM). We’re not late, we’re not over budget, we’ve just seen an early failure. In the space of a day the failures have been examined, dealt with and we’ve already got the next sprint backlog in place ready to go.
We don’t want to fail as individuals or as a team, but we’re not fearing it. Instead we’re actively working together towards addressing the issues and demonstrating working software at our next retrospective.