Recently I attended the first eXtreme Programmers London meetup hosted by Rachel Davies at Unruly Media. Talking to people there, and thinking about what Rachel wrote in her recent post on Sprints vs Iterations, I started thinking about what sort of rhythm and cadence is good for teams aiming at Continuous Delivery. What is it that we should try to do regularly, if anything?

In Scrum we work in a timeboxed “sprint”. We plan work to be done in the sprint, with the aim of having a releasable product increment at the end of the sprint. If all goes well we can release our new features at the end of the sprint. Many teams have evolved their agile process to include end-of-sprint ceremonies of showcasing internally, and releasing their work. So if all goes well, we plan once per sprint, and we release once per sprint.

In Kanban we pull new work items into play as there is room for them in the pipeline. Ideally we start at the right hand side of our development flow, and our first aim on any given day is to get the features we currently have in progress, released. Once we’ve reduced that work in progress by releasing something, we can pull in a new piece of work from the queue at the left of the board, which is prioritised by the business. We don’t have a timebox, or a regular planning or release time, we do each when we can or when we need to. There isn’t really a fixed rhythm.

In XP, there are timeboxed iterations, and planning occurs at the beginning of the iteration, but it was never the intention in XP that features should only be released at the end of the iteration. Everything can be released as soon as it is accepted by the customer. If we wait for the end of the iteration, then our process is causing us to keep work-in-process that is not yet released, and not yet delivering value to the customer. That is waste. We’ve made a rule for ourself, and the process becomes a bottleneck.

For some teams, especially in larger organisations, there can be external factors that affect when they can release. For example, a team in a bank that I worked with had a fairly kanban-esque process in terms of development work, pulling stories in when the team had capacity to work on them, but they could not release whenever they liked, as they had to co-ordinate with change control and operations teams. Releases happened once a week, on Thursdays. So for this team, the cadence was controlled by the external release team. The rhythm of the team was determined by this, rather than by a planning cycle. Planning happened on an ad-hoc basis, but releases always came on Thursdays. This could again be a bottleneck, building up unreleased features, but it wasn’t the teams choice. This is the sort of situation where developing more of a devops culture, and working together to try and achieve easier, more frequent releases could help to deliver value more quickly.

It may seem like a kanban flow, in an evironment where we are free to release whenever a feature is ready, would be the ideal. However, I do still see a benefit for teams of having some kind of regularly repeating rhythm - something that always happens on Mondays, or Fridays, or on the 1st of the month. Something to build up to and to work around. Without this I have seen team slip into a casual - it’ll be ready when it’s ready - work style. Having a regular rhythm driven by some aspect of your process does seem to help people to focus on getting things done - but it’s a difficult balancing act to make sure that what controls the rhythm doesn’t also cause bottlenecks that get in the way of delivery.

Continuous Delivery Course

I’m running a public two-day Continuous Delivery Kickstart workshop with Seb Rose in Paris in March. Why not come along to learn, practise and discuss?