Hi, thanks for the article. It gives a good introduction between Scrum and Kanban. It’s good that you emphasize that both Scrum and Kanban are possibilities to move to an agile way of working and to lead to improvements.
I certainly like your point that teams should be self-aware; and if they are new to agile – start with adopting an agile framework by the book (first stage of Shu-Ha-Ri).
There are differences and similarities between Scrum and Lean/Kanban. Both focus on delivering value to the customer. To reach this both make bottlenecks and impediments painfully visible in an organization and its processes, which should lead to actual improvements being made – otherwise you remain stuck; without delivering added value. There are some differences between Lean and Agile (Scrum) in the basic philosophy: e.g. regarding the strive for perfection and the way people are considered.
I would not stick to the prejudgement that Scrum or Kanban are optimized for a specific application. I am cautious to hear for example that Kanban is only for operations and maintenance tracks (if you’d ask David Anderson, he would certainly disagree). I am objective to all, and what suits the best is dependent on the organization’s context and situation.
It is true that Kanban is less prescriptive than Scrum – as a framework. Kanban it’s basically a WIP limited pull system to establish a continuous flow and to implement evolutionary incremental change to realize systemic improvements. With Kanban one measures flow to control and optimize for efficiency in flow from beginning to end. Kanban does not require you to change roles and responsibilities in the organization to form a team, and you start from the existing process. (On the other hand, I think Scrum is on a good spot on a scale of prescriptiveness when comparing to other (non-agile) project management methodologies)
The freedom you get in Kanban comes with more responsibilities: you have more options to organize yourself. For example: you can organize using iterations (establish a regular cadence as in Scrum); you should have a daily status team meeting align the work of the day (as in Scrum); you can establish regular review and retrospectives (as in Scrum). Otherwise around: in Scrum you can introduce WIP limits if you see too many items are consistently in progress and “not 100% done”. But remember: creating a visualization board or choosing a tool doesn’t make you agile.
Frederik