From Agility to Predictability: Is it Time to Jump on the Kanban?

by Sarah Lawfull

There seems to be some momentum gathering in the world of Kanban Systems. As Development Programme Manager at Caplin I pay attention to these things as I am always looking for ways to improve our development and delivery process.

From persona-led development ideology to my latest passion (Kanban Systems and "Lean" techniques), I like to ensure we’re not missing out on any opportunities to improve development and delivery processes.  

For those of you not familiar with Kanban Systems, here is a very short summary taken from John Sonmez’s blog: 

“The simple simple is this: Kanban is a pull model where you are strictly controlling work in progress (WIP) by limiting the amount of work that can be in each phase of development.  It eliminates the needs for time boxing and committed sprints and replaces it with just in time priorities and time in queue instead of velocity.”

"Lean" techniques are based on lean manufacturing or lean production and are focused on delivering more customer value, maximizing speed and flow and eliminating waste, with value being the highest priority of the three.  If you want to find out more about Kanban Systems and "Lean" techniques these four websites are a good start:

1. http://www.agilemanagement.net
2. http://www.limitedwipsociety.org
3. http://www.crisp.se
4. http://availagility.co.uk  

At Caplin we’ve been investing in agile training and using agile methods (a typical mix of Scrum and XP) for many years now. However, I think that as an organisation it is important to consider whether Kanban Systems and Lean techniques can be better applied to our development process to improve efficiency.  

At the moment we are trialing this new way of working with one project team, and I and a few other members of our engineering team attended the 1-day Lean and Kanban Exchange on the 1st December, run by the always excellent Skills Matter.

So what have we found?

Firstly, exploring Kanban has highlighted some of the drawbacks with the Scrum process and the use of it within our organisation. It’s very difficult to use velocity for Scrum sign-up because the team's personnel change frequently. The set time limits that are the cornerstone of the Scrum process can make taking on more urgent work (like critical support issues) a real challenge to the team.

We have found Kanban to be a lightweight process that shows bottlenecks quickly and one which produces good metrics and reporting. The method seems to create a constant flow of communication and a general sense of predictability – we have found that one of the key benefits of this method is this predictability, and that it is better to be predictable rather than to promise things that may not end up getting delivered.  Though that said, we are still exploring how we can provide a more accurate estimate on items that are much further upstream in the development process, but this I am sure is no different for all IT departments, whatever development method they use.

Our vision, should we roll Kanban Systems out across all development teams, is continuous releases where development teams pull work from priority boards with the work moving through the necessary stages. This would culminate in the final stage being “release into production”. 

What we’re aiming for is a blissful continuous work stream where capacity and demand are in harmony and value is pulled through the system and delivered to the business as early as possible.

Idealistic?  Not necessarily, but a swift move to jump on the Kanban Systems might be a little premature for us.  While we are all for anything that can help us to work more efficiently, Scrum works around the idea of set release dates, which makes project and resource planning easier for us and our customers.   We need a little more experience and investigation of the use of cycle times in the Kanban system along with the relationship of the size of the work placed in the queue before we relinquish Scrum.

Although it is true to say that development teams that have been following Scrum have certainly embraced Kanban with ease, there is much more work needed to consider the implications of changes on the business, in particular those that feed the Kanban systems and the fanfare of announcing new product versions.

While Kanban Systems could be quickly and easily adopted from the developer perspective, at this point we’ll continue with Scrum and will endeavour to measure and compare the effect of the two development techniques on in-house projects with bi-weekly cycles of Kanban Systems to see if this different methodology can improve the development and release cycle at Caplin.