Recently, I was reading some bits about Kanban system for Software Engineering. I thought “oh no… another Agile fancy word, which introduces hardly any value”. Well, after a few minutes of reading and thinking I must say one thing. Kanban is an Agile manifesto grasp in set of important principles. I must say, that it changed my way of thinking regarding Agile and how we have implemented it in our company.

There are two ways of implementing Agile – passive and active

Agile essence is defined in it’s manifesto. Based on it several tools that help working according to Agile principles were invented. Scrum, iterations, burndown charts, story boards, story points, user stories, scrum masters, project owners etc. There is much more than that.

Passive implementation of Agile – from tools to principles

Some companies are willing to implement Agile approach through tools like scrums, sprints, story points etc. They believe that by using these tools they will become Agile. This is partly true. Unfortunately, without understanding WHY scrum was invented, why we should have product owner etc. the Agile spirit is lost. That is why I call it passive. You don’t focus on Agile, you focus on tools and you believe that using them you have a correct approach.

Active implementation of Agile – from principles to tools

Kanban system introduces generic approach to Agile. There is no one way to became Agile. If you work using Kanban principles (which are derrived from Agile) you are working in Agile way. If this means that you have Scrum meetings with your team – fine. If this means that instead of Scrum your meeting will focus on remaining work – also good. Tools are very important but only when they help you follow your principles within company. Correct approach and tooling is a result of deep brainstorming and constant improvement process led by Kanban principles.

Kanban approach demands higher maturity from all team members

Because the whole team work is based on these very high level principles:

• Limit Work in Process (WIP)
• Pull value through (with WIP limit)
• Make it visible (Visual Control)
• Increase throughput
• Fixed Kanban Backlog
• Quality is embedded in (not inspected in)

Team members have to realize that they have bigger freedom but also – that they are responsible for keeping principles living in their teams. They have to understand them, and actively take part in the constant improvement process.

What is your opinion regarding Kanban for Software Engineering?