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…
Joe Blogs 