Funny you should ask – this ties in nicely with the topic of explicit policies.
Here is a short answer regarding DoR and DoD
Conceptually speaking, every station in a workflow has either implicit or explicit entry and exit criteria. The notion of a DoR and a DoD (as they have become widespread in the Scrum community) is modeling exactly this: having explicit entry and exit criteria for a system with one station.
When modeling a system with Kanban, those definitions for ready and done really need to become part of the often mentioned explicit process policies.
Let’s take a look at a simple example.
Assuming we have two stations A and B –where work flows from A to B– we look at B first, honoring the principle that we work on Kanban boards starting at the point closest to the value generation: the customer facing side.
| station A | station B | | doing | done | doing | done | | | | | | | / \ | / \ | | / \ | / \ | | /DoR B\ | / \ | | ( ⊆ ) | ( DoD B ) | | \DoD A/ | \ / | | \ / | \ / | | \ / | \ / | | | | | | | | | | |
In this scenario the “Definition of Ready” (the entry criteria) for station B has to be part of the “Definition of Done” for station A. Why? Well, the “Definition of Done” for station A is the DoD for the Doing column of station A. Once a work-item leaves the “Doing” column nothing should be done with it – after all it has left one Doing column and not yet entered another Doing column.
Therefore when B pulls an item it will – or at least should – be exactly in the state it was when it left the Doing column of station A. That being said, there may of course be additional rules governing the entrance to station B (e.g. if the item is part of a multi-part workflow).
For the topic under consideration “Do we have a DoR and DoD in Kanban?” the short answer would be “yes”.
In any life-size system, where we have more that two stations, multiple sets of entry and exit criteria make sense – one set per station (column). Whether we focus on the DoR or on the DoD first, is a matter of focus. Both approaches might be appropriate.
Taking this further, beyond A and B we get something like:
| station A | station B | Station C |… | doing | done | doing | done | | | | | | | | | / \ | / \ | | | / \ | / \ | | | /DoR B\ | /DoR C\ | | ( ⊆ ) | ( ⊆ ) | . . . | \DoD A/ | \DoD B/ | | \ / | \ / | | \ / | \ / | | | | | | | | | | |
From my experience, it is helpful to start thinking this through from the right hand side and consider the DoRs first. But then again life is complex and depending on your actual situation there may be other approaches that make sense.
Ceterum censeo: Of course we can model everything we have in a Scrum process with a Kanban system. Both operate at different levels and Kanban is meant to be able to model existing processes. The question whether you should move from one to the other is non-sensical by definition but conversely adding Kanban to Scrum actually makes a lot of sense.