{ 2009 06 08 }

Patterns of software engineering workflow (part 1)

Comments (18)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Part 1 of a three-part series

Any kanban-controlled workflow system can be described by combinations and variations1 of a basic pattern:

kanban

Sometimes we can simplify the diagram by replacing the kanban backflow with a simple capacity parameter2, but often it is better to show the flow of kanban explicitly.  Many of the software development kanban systems we’ve seen are simple workflow systems composed by chaining this basic element:

workflow

I would like to think that any professional software engineer would be able to think up more interesting workflows than just a linear cascade.  Then again, I would also like to think that any professional software engineer would understand the value of keeping things simple.  I have personally come to prefer a more symmetrical call-stack style of flow for software development, because I believe that any person who requests custom work should also be responsible for approving the completion of that work. Consumers pull value from producers, not the other way around:

symmetric-workflow

Petri nets are ideal for describing workflow systems because they are a) concurrent; b) formal, simulable, and sometimes even verifiable; and c) relatively easy to read by humans.  Any Petri net that can be drawn without crossing edges can easily be made into a “card wall” for visual control3:

cardwall

Sometimes a different workflow is needed, depending on the kind of thing being made:

or-branch

Some tasks can be done in parallel by specialized resources:

and-branch

When we split tokens, we may need to keep track of their common ancestor so that we can merge them again.  Colored Petri nets let us associate composite work items across branches:

color

Sometimes a large work item can be decomposed into smaller work items of a similar type.  We might think of a branching workflow to model this, but that is hard to do if we don’t know how many component work items will be created.  Petri nets allow us to take another approach by generating new tokens in-place and then executing them concurrently on the same workflow branch:

decompose

When all of the unit work items are complete, they are integrated into their parent work item:

compose

While that might look a little complicated, in practice it’s as simple as the “2-tier” style (or n-tier) cardwall that is often used for project management:

cardwall2

A state transition is a black box that may have some internal process.  We might expose that process with a hierarchical model.  Alternately, we might want to collapse extraneous diagram detail into a single supertransition.  Hierarchy is a simple syntax extension to any workflow model.

Feedback should be considered implicit to any creative process, but it can complicate these models without much benefit to understanding4.  In practice, kanban systems regulate feedback very well, because the limits serve as a ratchet function that gracefully responds to feedback and damps oscillation.  A process operating at capacity will not accept new work, and a process operating over capacity will also not accept new work.  Again, it’s awkward to model “over capacity” so we have to be mindful to treat our models for what they are: models.

Once we understand some of these basic design elements, we can use them to describe or design a wide variety of product development processes.  A computer scientist armed with Petri nets and a bit of knowledge about queueing, networks, and processor scheduling has some wicked tools at his disposal for Value Stream Analysis.

1. Some variations involve rules about queue placement and timing of the kanban backflow. GKCS and EKCS are examples in the literature. I wrote about some of that here.
2. Whether or not you can simplify in this way depends on which queuing rules are used.
3. I debated using the blink tag for this point.
4. You can usually cheat by adding an “escape” transition to send all feedback to the beginning of the model and allow it to repropagate downstream without friction.  Feedback is easier to account for in matrix representations than in graphic representations.  Feedback in a dependency matrix looks like row elements or “rabbit ears” on the “wrong” side of the diagonal.

Posted by Corey Ladas on Monday, June 8th, 2009, at 12:00 am, and filed under kanban, lean.

Follow any responses to this entry with the RSS 2.0 feed.

You can post a comment, or trackback from your site.