Kanban and Back Again: Lessons Learned in the Continuous Search for Agility

  

 Email Article  

Tweet  

  

As part of our ongoing search to improve the way we deliver software, we recently tried Kanban on a new development effort.  Ultimately, we ended up taking some of the positive aspects and going back to more Scrum-like process, but the effort was very worthwhile.  OpenLogic has been using agile practices for many years now. Like most  things, the results are cyclical. Get comfortable for a while and then something changes and forces a period of adjustment. Thus it is important to continually review in order to recognize when change happens that affects processes (and let's face it, change happens very quickly in this industry). Luckily, as engineers, we embrace change.  We had the opportunity to look at a radical shift  in our agile processes due to starting new development on our CloudSwing product and Kanban fit with some of the ideas we had been discussing. CloudSwing gave us the ability to try out these new ideas without incurring some conversion costs for our much larger codebases.

Pros:

Small, incremental releases - We have worked with many release schedules, from long releases with 4-5 sprints to shorter cycles usually defined by an amount of time such as a single 2 week sprint.  With Kanban, the idea is that as each feature is ready, it can go to production.  This fits in well with what has become one of the most important tenets of our development processes: get code to production and in use. Code not in use can get stale.  Code in production gives a sense of accomplishment. It also reinforces that each feature must be always ready and tested for production because that's where it's going next.  Small releases ease the regression burden on QA and helps us remove drift from a stable system.

Work in progress limits - When you are a small team or a small company, there are always competing demands for time. By highlighting when people are working multiple tasks, it brought more awareness to the times when task switching was becoming a problem.

Cons:

Mid-term planning difficulties - Many Kanban users have said they have found no need for estimation. Kanban also seemed to be better suited to blocks of work essentially the same size. In that case, a trend of how long it takes to start and finish similar blocks of work can be translated into a form of predictability that can be used to plan the delivery of future features. For us, in practice, it was exceedingly difficult to design features of near equivalent size. It became more difficult to keep a connection between the mid-term planning and the actual story planning. This was also made more difficult by the next item.

Tooling - We have some pretty simple rules about the tooling we use to help manage our process. They can't get in the way. When things get a little crazy, the tools should help us manage the chaos, not feel like a hindrance. Using this criteria (and not breaking the bank), we evaluated several tools that seemed like they would work for our needs. Although each tool seemed competent at basic Kanban management, every tool including the one we ultimately chose seemed to be lacking in one way or another. Most importantly, the tools made it difficult to track history, plan ahead, and lacked a robustness in the data model that we were looking for.

Take Away:

Ultimately, we decided to return to a modified version of our original scrum process.  We implemented what we felt was the biggest gain from our use of Kanban: the small, incremental release. Scrum sprints essentially take shape behind us now as we work toward releasing as much as possible when it's ready.  Embracing a continuous release philosophy also has a significant impact on many other aspects of our development toolchain. Long testing cycles can hamper our ability to release as fast as we would like so we are taking steps to streamline the regression suite. Complex codebases with tightly coupled architectures increase the risk of even small changes to impact unexpected parts of the system so we are identifying areas where we can decouple sections of the codebase and release them separately.  We are redesigning our release processes so they can accomodate live deployments and help minimize the downtime often associated with releases. These are all things that we continue to work on as we strive to incorporate Kanban ideas into our Scrum process.

Kanban is a fine methodology that ultimately didn't work out for our team (at this point in time), but it contained valuable ideas that we have used to become a better development team.

Subscribe to The Enterprise Open Source Blog by Email

Follow @openlogic
Follow @cloudswing
Follow @esweid01



This work is licensed under a Creative Commons Attribution 3.0 Unported License
.