I’ve written before about the dangers of complacency in an Agile environment. Once you have established daily scrums, Kanban boards etc, it’s very easy to stop asking bigger questions about your software development process. One of my favourite concepts in Agile to examine closely with a team is the Sprint (AKA Timebox or Iteration).
In classical Scrum (I’m not 100% sure when it became “classical” Scrum), the entire process is driven around a single, time-limited Sprint. DSDM has an almost identical concept called the Timebox. Other teams call this the iteration.
The Sprint looks something like this:
| Monday | Daily Scrum |
|---|---|
| Sprint Planning | |
| Do some work | |
| Tuesday | Daily Scrum |
| Do some work | |
| Wednesday | Daily Scrum |
| Do some work | |
| Thursday | Daily Scrum |
| Do some work | |
| Friday | Daily Scrum |
| Do some work | |
| Deliver Software | |
| Sprint Retrospective | |
| Sprint Demo | |
| Measure Velocity |
My example uses one week Sprints. I also haven’t included estimating as a separate activity (it is part of planning here).
Why should all of these activities revolve around the same fixed Sprint period?
Let’s take planning / estimation to start with. My team estimates for five minutes or so every day. Sometimes we have nothing to estimate, sometimes we do a little more than five minutes. Our environment is very dynamic and we have to deal with rapidly changing circumstances. From a commercial perspective, we can’t wait until the following Monday to estimate and plan new work in!
I think that a lot of teams now are delivering much more frequently than once per Sprint. In a very fluid environment where value for money is key, teams are delivering on an ad hoc basis. We have invested heavily in great automation to get our software into production in less than five minutes. Why would we want to wait until Friday afternoon to do a release???
Similarly, a team working in a safety critical environment may not be able to release on a weekly basis due to regulatory or legislative reasons. The deployment process may be so (necessarily) arduous that it is only realistic to release once per month.
We service a lot of clients simultaneously. This means that we can’t demo all of our software on the same day. Sometimes we need to do more than one demo per week when are releasing important functionality. Most of the time our customers are inconveniently not available on Friday afternoon! We have to schedule these things in a much more ad hoc manner.
As a small, tight team, we also don’t feel the need to do a retrospective every week (I’m aware of the irony of this!). A larger team may have a much greater need for the formal opportunity to give feedback and make changes.
What are the benefits of working in sprints?
The key benefit of a Sprint for my team is measuring velocity. We always measure our velocity weekly. HOWEVER, I would see nothing wrong with a team that wanted to measure their velocity every two weeks (as that may give a more stable value), but still do all of the other ceremonies / activities above on a weekly basis.
The key lesson is that the Sprint / Timebox / Iteration should set us free, not constrain us. Don’t feel that everything in your Agile process has to follow the same rigid time frame. One size doesn’t quite fit all!
Get in touch with our team to learn about range of Agile Services and Workshops to kick start your transformation.
