I attended a Kanban training course in early March and took some notes. Here’s a very slightly edited version of my notes.
We performed a small thought experiment and game, with the overall take away being
Smaller batches are better than bigger batches in general
Call these batch sizes Work in Progress (WiP) limits.
We discussed an existing workflow with states and substages and WiP limits:
|substages||doing - complete||ready||doing - complete||ready||ready|
WiP is really tough to figure out at the start. We will get this wrong.
A workflow can have multiple points of entry, but it should have one point of exit. It’s possible to have more but aim for one.
You measure certain interactions on a regular basis, and these metrics are:
Work in Progress
Work Item Age
Service Level Expectation (SLE)
Average Cycle Time
SLE and Average Cycle time metrics are related and affect each other.
We used a game called TWiG to try out different strategies and WiP limits. Two peers and I made a group and tried a bunch of different ideas.
We focused on making sure work moved between columns, choose which work to do based on what could finish, and generally prioritized work in the green column to finish over any other work.
We followed the same strategy as first with the only difference being lower WiP limits. We never hit them in the first game except for the red work.
We approached this with a much different strategy. We moved WiP limits to 1 1 1 and tackled any blockers that came up first.
This was a game, so the level of abstraction and simplicity made us question exactly how much this could model real life software development. Can you know exactly how much work someone can do or a task will need to be done? Can work ever move backwards? Does the idea of red workers being good at things in the red column really match or mean anything? What happens with bugs found in the Blue and Green stages? Interruptions seem way more common in reality, but it was nice to see them included here.
We did find have some learnings out of all of this:
We examined an example board to talk about a few things.
Ready is the first stage with Pull, so it is the first point of commitment. There is no commitment to the work item before it reaches that stage. This gives an opportunity for Just in Time prioritization and commitment.
SLE should be based on existing data. I think it should be required for Kanban. It is how we can tell customers how long something will likely take once committed.
Items in the backlog should be right-sized but not necessarily same-sized. Can this item be completed within the SLE? This is the point with the least amount of information. If the conversation leads to yes, then the conversation is over and the team can start the work. If it leads to no, then is this the right thing to work on? Can it be split or reduced in normal ways?
Things moving between stages, into the Ready column, backwards, or not moving should generate conversations between the product owner and members of the team.
This list was the instructor’s recommendation for what’s most important to figure out first: