Managing WIP through a process

There’s a great book comparing Scrum and Kanban flavors of Agile software development. Scrum is more prescriptive than Kanban and it’s probably more widely adapted by software teams. Kanban is much more lenient. Both are ways to manage wip (work in progress) through process.

Here are the similarities, according to the book, Kanban and Scrum: Making the Best of Both:

• Both are Lean and Agile
• Both use pull scheduling
• Both limit wip
• Both use transparency to drive process improvement
• Both focus on delivering releasable software early and often
• Both are based on self-organizing teams
• Both require breaking work into pieces
• In both, the release plan is continuously optimized based on empirical data (velociy/lead time).

But, they reach manage wip differently. In Scrum, wip is managed indirectly by only committing to work during a sprint (2-4 weeks) based on previous team performance (velocity). Once the sprint starts, teams cannot add more work to the sprint. Therefore, they can only commit to so much and therefore an implied limit on wip based on the sprint length.

In Kanban, wip is managed directly because it’s limited to a workflow state.

The numbers 2 and 3 are the wip limits for the corresponding columns. The wip for the 'develop' state is shared between OnGoing and Done. Credits to Kanban and Scrum: Making the Best of Both

There’s a lot to be learned from Kanban. Kanban is talked about in length in The Pheonix Project. Many teams could use some Kanban practices to help improve flow and value delivery. For example, it’s easy to apply wip limits using Azure boards.