Kanban and Scrum – Intention and Implementation

In my last post I introduced the idea of a PVC System – one which exemplifies Pull, Value and Capability – and closed by posing the question as to whether Scrum could be considered to be a PVC System. In answering that question myself, I realised that there is another distinction which I will describe in this post. In doing so, I am also re-entering the great Kanban and Scrum debate, with the goal of learning rather than fighting!

The XP Community popularised the concept of programming by intent; writing code which describes what it is doing rather than how it is doing it (programming by implementation). I believe the same distinction can be used to describe methods, and can help differentiate Kanban and Scrum. Kanban is an intention-revealing method. The intention is to reveal the workflow, visualise the work, limit work in progress, establish a cadence and continuously improve. How to do that is up to the team. They can use any workflow, visualisation, WIP limits, cadence or improvement mechanisms. Scrum on the other hand is an implementation-revealing method. The implementation is described in terms of the Sprint and the associated roles, meetings and artefacts. Even if the implementation is described in abstract terms, as Tobias Mayer does, (and Tobias’s interpretation of Scrum is one I respect greatly) I still consider it to be focussed on implementation.

This is not to say one is better than the other. An implementation is ultimately required, and Scrum has proven to be a very good one with which I have had considerable success. But is Scrum a PVC System? I think it can be, if implemented with an intention-revealing mindset. If the Sprint, roles, meetings and artefacts are implemented in way which reveals the workflow, visualises the work, limits work in progress, establishes a cadence and continuously improves, then it will be implemented with the right intent. I expect that most cases of “Good Scrum” will fall into this category. On the other hand, if the Scrum Sprint, roles, meetings and artefacts are implemented in a mechanical way, then I suspect that the workflow will remain hidden, the work will not be visualised, work in process will not be limited, a cadence will not be established, and continuous improvement will not happen. This is when we get cases of “Bad Scrum”. Thus ScrumBut is not when the Scrum practices aren’t followed per-se, but when they are followed with the wrong (or no) intent.

So Kanban and Scrum are like apples and oranges (to jump to an different analogy). Both are good for you, and both can go together – with other fruit – to create a tasty fruit salad. But they are different. Kanban is intention-based and Scrum is implementation-based.