How to combine continuous delivery cycle with iterations?

Question

I'm the leader of a small team (a few programmers, plus product manager) practicing continuous delivery. The development stages for features are:

1. Coding: A programmer prepares a branch with the feature, up to a specification. The feature is reviewed by Product Manager at the end of this stage.
2. Code review: Implemented with merge requests. A fellow programmer looks at the code, points out issues, programmer works to fix them. When everything is OK, the feature is integrated to main development branch.
3. Deployment: after passing the automated tests suite, the contents of main branch gets pushed to production servers. This currently happens twice a week.

For planning our work, we're using 2-week iterations - Product Manager proposes feature to work on, we estimate them, and based on that allocate them to programmers for the iteration. My questions are:

1. During an iteration, what should we commit to? Right now we're saying that by the end of iteration, the coding (stage 1) has to be finished. This is because there might be some delay between coding and review (since the reviewer is also working on something).

   I'm a bit hesitant to include all 3 stages as required to finish, because this means by the end of iteration, everyone is working on code review, instead of the features following their development cycles unconstrained.

2. How much should be planned regarding delivery date? With the current setup, we can only say that the feature should be deployed sometime during the next 3 weeks (iteration + a window for code review and deployment). Can we do better? Should we?

3. Because of the above: how much should we plan regarding work ordering? Should we, for instance, say during which days which features will be worked on, and reviewed? Or specify a strict order in which the features will be worked on during an iteration? Or give the order as priorities, but allow more freedom?

   Again, I don't want to constrain the programmers too much here. Detailed up-front planning doesn't sound very useful for me, and the actual ordering of work is something I'd rather give freedom at as well (perhaps with the priorities as a soft guideline). But I'm not sure if that makes the delivery date much more certain.

Answer 1

Rather than answering each of your questions separately, I'd like to share how we implement CD at our end. Hopefully you'll find this info useful.

Requirements Planning

• All of our stories are the same size - we don't do relative story sizing anymore. Furthermore, our story slicing method mandates that the estimated "dev" effort does not exceed 2 days (to push to staging) for any story.

• Our project plan contains the following Horizons: Releases, Features and Stories.

  • 2 or a max of 3 stories comprise a Feature, So, a feature is about a week long.
  • 4 to 6 features in a release. So, a release is about 1 to 1.5 months long.

• We use the "average cycle time" metric (from Kanban) to track our progress against the above schedule.

Dev Practices

• We stopped using branches a few years ago. All of our code is directly checked into the master branch. Of course, devs are expected to checkin to the master only if all tests pass on their local environment.

  • Feature Toggles are very useful in those situations when code is checked in, but the corresponding feature is still pending review from say, the product owner. As long as the number of toggles is kept to a minimum, this is a very useful technique to maintain "flow".

• We practice pair programming - so code reviews are done almost always while the code is being written. Once in a while though, we do switch pairs or get reviews done by members outside the team. CodeClimate is also pretty cool - in helping us keep our technical debt low. [We also love the alerts from CodeClimate - they're useful triggers to refactor certain neglected parts of the code]

Answer 2

If you can release every couple of days, it makes sense to stop thinking of things in terms of batches (iterations) and start focusing on the flow of work through your process.

Kanban, for example, doesn't use iterations but prevents overloading and allows predictability by limiting the amount of work that can be in any given stage in your delivery pipeline at one time, and measuring the rate at which you deliver features (rather than velocity as in Scrum).

There is a good guide available here: http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf

I also recommend reading 'Kanban' by David Anderson.

As far as answering your specific questions:

Focussing on flow rather than on a batch commitment removes the need to jump everyone onto code reviews at the end of an iteration. I won't dwell on this one since it's a problem that just goes away if you're not doing sprints.

Rather than doing a planning session every two weeks, perhaps spend a few minutes every morning where the product owner reviews progress of things in flight and has the opportunity to re-prioritise the backlog.

In terms of planning and work ordering, I prefer to have a prioritised list to work though and would never recommend trying to assign work or specify what day something will get done.

When a developer has finished a task, they should look at the board and decide what needs doing next. Finishing things should always take priority so if there are things that can be pushed to live or need code review, these should be done in preference to starting new work.

If they can't work on anything in progress, they should take the next item in priority order to start coding.

I'd encourage them to take initiative and not just blindly pick the next task though. If the second priority item is something they have particular skills or knowledge to do best, by all means pick it up.