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 a 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 its manifesto. Based on it several tools that help to work according to Agile principles were invented. Scrum, iterations, burndown charts, storyboards, 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 an 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 a 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 a generic approach to Agile. There is no one way to become Agile. If you work using Kanban principles (which are derived 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 the 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 teamwork 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?