Applying Kanban to IT Processes 5: Kaizen

In the last article of this series Eli Weinstock-Herman discusses some of the most popular issues with implementing Kanban and brings the concept of continuous improvement closer to our understanding.

Making the effort

The first issue with implementing Kanban, described as common and quite an expected one really, is the necessity for the whole team to change their habits. This goes both for adjusting to the WIP limit (and stopping multitasking), and to the way that the results of the work are perceived. Whereas before, the team may have been used to report on how many hours they've done or how many tasks they've completed, with properly applied Kanban the questions the team will be asked are: how many hours were saved, how can you improve the way you work, how much more was delivered by the entire team, rather than by one member? This certainly takes some adjusting to, but Eli ensures that it only takes a moderate amount of effort to get used to a new model and that it is certainly worth it.

Manufacturing software?

The other problematic matter that IT people often bring up when considering implementing Kanban (and Agile in general) is the somewhat funny argument that IT is nothing like a manufacturing process (originally associated with this methodology). There doesn't seem to be much merit to this at all. Adopting good practices from one industry to another makes perfect sense, as long as it brings about a positive change. Kanban has proven successful in many branches of work and no amount of philosophical dispute can really change this.

Reasons for doing Kanban

The most prominent cause for sticking with Kanban for Eli is the clarity and consistence that it brings to his team's work and to the way that they go about it. Applying a system to the software creation benefits the team with better understanding of what's going on, what needs to be done, what certain tasks will entail (basing on previous task completion). A certain amount of uniformity results with much appreciation for the work that comes along. Also, thanks to the transparency level of a Kanban process, they are much better suited to foresee and resolve any bottlenecks.

Kaizen

What Eli underlines as the greatest benefit of applying Kanban to software development is the possibility of a continuous improvement (kaizen). Thanks to the little (and large) changes that doing Kanban demands from the team, the general process gets better all the time. By cutting waste, better understanding of what's expected, process visualization and impediment anticipation - the team is able to really make the best use of their time and resources. Eli makes a sharp observation, that even though Kanban allows for a productivity increase, ways to make it reduce costs or increase quality of work are not quite as obvious and demand a little more effort and work on perfecting the internal process. This work would consist mainly of redirecting the team's focus and perfecting the task assignment process.

Further possibilities

At the end of the article, Eli brings us some more ideas on the perfect environments for implementing Kanban. He mentions processes of support teams, PC deployment services, report creators, database and system administration. Eli remains convinced of Kanban's value to IT processes. Are you?

Read our article on Kanban for software development »