Archive

Posts Tagged ‘sprint’

If I Shorten the Race Can I Sprint Faster?

June 19, 2009 Comments off

When Point2 adopted Scrum over a year ago we started with 30 day iterations. The process was new to us and it seemed like a reasonable starting point. As we ironed out our practices and got more experience we naturally started to make changes to improve how we did things.

After running through a few 30 day Sprints we soon realized that they were just too long. We were finding that at the end of the Sprint we were unable to remember what we did at its start. This became glaringly apparent during retrospectives. The decision was made to move to two week Sprints, and that is they way our six teams have been operating ever since.

My team had been throwing around the idea of shortening our Sprints even further over the last few months, but at our last Retrospective we decided to actually take the plunge. Even though we were being reasonably successful with two week iterations, we still felt that we could go faster. One week (5 day) iterations seemed like a good way to help take the team forward.  Here’s how we think the change will affect the team.

  • Even though two weeks was not long, it still left enough room for a large amount of stories to be part of the Sprint. This meant we had a broad focus.  One week iterations would allow us to easily visualize the Sprint. Our focus would be much sharper
  • One week Sprints would hopefully allow us to better accommodate change that comes in an Agile environment.
  • With weekly retrospectives would come more organized discussion to fine tune our process even further (that’s not to say we would not continue to make mid-Sprint changes if need be).

The team plans to make the transition at the start of the next Sprint. We understand there may be a bit of extra overhead in regards to planning and estimation meetings, but feel that these will get considerably shorter, having less impact on the actual Sprint.

Without actually having tried it yet the team just has a “gut” feeling that this will make us go faster. Just think about it for a second. If you are in a 400 metre race, you will have to run at a slower pace in order to finish. Cut that race down to a 100 metres and you should be able go to all out. I look forward to seeing how this will impact the team and will do follow-up posts reporting on our progress.

By Hemant J. Naidu

Why Did That Happen?

May 15, 2009 1 comment

During our Sprints it is not uncommon for some problem event to occur.  Such events could be anything from a story taking considerably longer to complete than it was estimated to take, to a production bug being injected into a Sprint.  As a team we would usually acknowledge these events in our retrospective and make a few brief comments about how to eliminate similar occurrences in the future.  It seemed however as though we would promptly forget about the problem…until it happened again.

After seeing these problem events continue to occur, my team started throwing around the idea of doing root cause analysis. The hope was to get to the bottom of why these things were happening in the first place.

At first we were not quite sure how to conduct a formal root cause analysis, but after a little research we got ourselves pointed in the right direction. Our first analysis was a great exercise in drilling down into the heart of something the team saw as a problem. By focusing on one specific problem we were able to:

  • identify a plethora of individual areas that led to the problem in question.
  • isolate causes that could immediately be acted upon.
  • identify causes that we as a team could not solve alone.
  • bring causes into the foreground spurring discussion, and setting the team up to be mindful of them in the future.

As a team we have seen the benefit of analyzing our problem events and have integrated root cause analysis into our Sprint cycle. Just like we have a retrospective at the end of the Sprint we also have a root cause analysis session. One team member is responsible for presenting a problem event to the team and leading the analysis. To date we’ve done this three times and have used two different methods of analysis (Ishikawa Diagram, Cause Mapping). The way the analysis is run is completely at the session leader’s discretion.

We’ve already started to deal with areas that were immediately actionable, and have at least started to get the ball rolling in some areas that require a little more thought and organization. It is no doubt in my mind that as my team continues to identify and eliminate the root cause of our most crippling problems we will reach that hyper-productive state that so many Scrum teams strive for.

By Hemant J. Naidu