Lean Software Engineering

You might think there’s only so much one could say about moving sticky notes around on a whiteboard, but no, there’s still quite a bit left to cover on that topic. One of the nice things about computer science / informatics is that it provides us with such wonderful tools for describing the behavior of complex systems, especially for event-driven systems like our kanban-regulated software development workflows. If we have a lot to say about this subject, it might help to say some of it in more precise language.

This Petri net diagram describes a basic module of the type of kanban system that we’ve been using to manage software development processes. This is a simple pending->working->complete workflow, but this module can be chained together to add additional steps.

The example has a WIP limit of 3. If all 3 kanban tokens are in the busy state, then no tokens will be available, so the work item transition from pending to in-process cannot fire. As soon as an in-process work item completes, then a busy kanban token will return to the available state, and enable the transition of a new work item out of the pending state.

A curious thing about our model here is that it does not impose any queueing order. A manufacturing system might have a FIFO queueing rule, and therefore require some additional model detail. Our system has no such limitation, so our simple little model is pretty representative just like it is.

We can describe additional features of real-life workflows by using the Color and Hierarchy extensions to Petri nets. There are also other variations of the kanban signaling mechanism that we might tinker with. But we should be able to describe most anything we can think of, and I’ll revisit this topic in a coming article.