Introducing Iterations

New year, new start… We’ve just got a big release under our belts and it feels like there is now enough trust from senior management to start making a few changes to the way we do things.

So what first..?

One problem seems to be the feedback loop from the business. They come up with an idea, it spends a few weeks/months being spec’d up, and then we develop it. Finally it gets tested and eventually the business owner gets to see the ‘finished’ product…

This sounds okay in practice, but it doesn’t work because things change along the way.

We need to tighten the feedback loop so the business are involved and engaged throughout the whole of the design, develop, and testing process.

Another problem is that time is wasted in spec’ing up features that never get delivered because we then run out of time in the development phase.

Ultimately we need to move away from the long phase-based waterfall approach that makes the flawed assumption that we can get everything right and complete in one phase before moving onto the next.

Pull?

I think the ideal solution to this will be to introduce a pull-based continuous-flow pipeline type of approach. We’d take one minimal marketable feature at a time and deliver it all the way through the pipeline from start to finish.

Although this type of Kanban approach says ‘start with what you do now’ – I see us having the problem that this is going to require a lot of regular communication and engagement between different teams, who work in different geographical locations. The organisation isn’t currently used to this level and style of communication.

Iterate

After some thought, I reckon it’s probably going to be better to try an iterative approach first.

We’ll try working in two week iterations; taking a small chunk of work at a time – maybe a couple of features – developing and testing them, and then finally demo’ing them to the business owners to get approval that we’ve done the right thing, and/or feedback that we need to change things.

By getting this early and regular feedback we should avoid the nasty surprise of finding we’ve delivered something incorrectly right at the end of a release when we don’t have the time to do anything about it. Ideally if something is going to fail, we want it to fail as early as possible! We can tackle high priority and high risk items in the earlier iterations, to drive out risk, and ensure we’re delivering the core requirements early on.

My reasoning of choosing iterations over continuous flow, is that because of our split site, it will be good to have specific markers in time where the different teams can come together to look at where we are, review progress and then plan the next steps to take.

I actually hope that over time the iterations might naturally disappear and we’ll end up with the continuous flow system that will work even better in the long run. Until then I think that introducing the discipline required to make an iterative approach work, will be a good thing…

Input Queues => More Output

One of the first ‘quick wins’ that we’ve implemented is to let the development team manage their own workflow. A bug tracking tool was in place when I arrived (a good thing as there were a LOT of bugs, but more on that later) but the process in place was for Project Managers to ‘manage’ these bugs by assigning up to three bugs at a time to any given developer.

Maybe it gave the PMs some sense of security that ‘all bugs are assigned, therefore we will fix them and deliver on time’ but I’d argue that this is a false sense of security.

There are a few other things wrong with this approach:

  • How can a developer be working on three things at once?
  • How does the PM know the best person to work on a particular bug?
  • Not all bugs are equal – one might a be a tiny copy change, another could mean a fundamental problem in an important component.

We resolved this by introducing the concept of a prioritised input queue. Between us, we (Dev Team Leads) and the PMs would triage new bugs into the queue, constantly re-prioritising it so that we have collective control of which bugs get looked at next.

The developers then just have to pick the next bug off the list that makes sense for them to work on. We’d usually set some rule like ‘you have to pick from the top three bugs’, so that Developers have some control and ownership of what they work on, and still ensuring they’re working on the one of the most important things for the business.

In our case the input queue was a physical one – a new column on the Kanban board that’s in place on our giant whiteboards. We’d add a new post-it to the input queue for each bug triaged into there.

This worked well as it reduced the amount of time wasted in context-switching every time a developer was ‘assigned’ a new bug, and each bug got to the relevant person more quickly and with less fuss. The hardest part was persuading the PMs to relinquish the perceived control that they had over the process.

By introducing the input queue, we were able to demonstrate that we’d be able to waste less time, and therefore fix more bugs, by managing our own workflow.