Daily nuggets

Domain knowledge (problem and solution) is the raw material from which information systems are constructed–the source of the value stream.  Well, that and computers.

The software development pull system representations we have seen so far are not the end.  There will be a good deal more evolution of that line of thinking.

Comments (0)

Print This Post Print This Post

Email This Post Email This Post


Patterns of software engineering workflow (part 1)

Part 1 of a three-part series

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


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:


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:


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:


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


Some tasks can be done in parallel by specialized resources:


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:


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:


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


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:


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.

Comments (18)

Print This Post Print This Post

Email This Post Email This Post


Make a place for good things to happen

Motherhood and apple pie

A staple of software engineering research is the effectiveness of design reviews and code inspections for discovering defects.  Methodologists love inspections, but they seem to be difficult to sustain in practice. I’ve seen a few typical reasons for this:

  1. Inspection is a specific skill that requires training and discipline.  Naive, unstructured “code review” is worse than useless and eventually self-destructs.
  2. Inspection is quick to be dropped under acute schedule pressure, and slow to restart as a habit once it has been broken.
  3. Inspection works well for frequent small batches and badly for infrequent large batches.

Reason 1 is a matter of skill, and can be solved with education.  Reasons 2 and 3 are process issues.

The “inspection gap” illustrates a curious aspect of human nature.  There are certain behaviors that a group of people will agree should be practiced by its members.  Individual members of the group, when asked, will say that they believe that members of the group should practice the behavior.  But then, in practice, those same individuals do not practice that behavior or practice it inconsistently.  If you point this out to them, they may agree that they should do it, or even apologize for not doing it, and then continue to not do it anyway.

In my mind, this is a good part of what Lean thinking has to offer.  Lean methods like Visual Control recognize this aspect of human nature and provide people with enough structure and context to act in a way that is consistent with their own beliefs.  If people using a Lean process agree that code inspections are a good idea, then it will not be hard to get them to agree to incorporate inspections into the process in a way that is hard to neglect.  Lean strives to make it easier to do the right thing than do the wrong thing.  Lean helps people align their actions with their values.


One practice that works well in most workflow systems is the simple checklist.  Human attention is a delicate thing.  People get distracted, make mistakes, and overlook things even when they know better. A checklist is a simple device to keep your intentions aligned with your actions. Doctors who use checklists deliver dramatically improved patient outcomes.  Would you get on an airliner with a pilot who didn’t use a pre-flight checklist?  Would you get on an airliner controlled by software that was written without using checklists?

Checklists and kanban are highly complementary because you can attach a checklist directly to a kanban ticket and make the checklist part of the completion transaction.  Checklists improve confidence and trust, and expose tacit knowledge.  Checklists relieve anxiety and reduce fear.  Can you think of any part of your development process where you’d sleep better at night knowing that all of the important questions were answered correctly by somebody you trust?


Checklists work well for individual activities that do not require specific sequencing, but they don’t work as well for activities that require collaboration from people who have competing commitments.  We can raise the stakes for everybody if we elevate our checklist item to the workflow and subject it to the pull discipline.  That makes your problem everybody’s problem and gives your peers sufficient incentive to collaborate.

Inspections are a typical example at the scale of a single developer, but there are other practices and scales that we might consider.  Failure Mode and Effects Analysis (FMEA) is another highly effective technique that many people agree with in principle but find difficult to implement in practice.  FMEA is a systemic method and often targets components or subsystems that are much larger than “user story” scope .  Security lifecycle and regulatory compliance activities may also fall into this category.  An advantage of using composite workflow is that you can schedule activities that apply to different scales of work.

Process retrospectives can also be attached to workflow in this way.  Compared to a more open-ended periodic retrospective, a workflow-bound retrospective asks a more specific question:  How could we have created this work product more effectively? Such a workflow-based retrospective directly implements Deming’s Plan-Do-Study-Act cycle.

Are there any practices you would like to see your team use consistently, but have trouble fitting in to your schedule?

Comments (3)

Print This Post Print This Post

Email This Post Email This Post


Shingo on cargo cult kanban

What is the Toyota Production System? When asked this question most people (80 percent) will echo the view of the average consumer and say: “It’s a kanban system”; another 15 percent may actually know how it functions in the factory and say: “It’s a production system”; only a very few (5 percent) really understand its purpose and say: “It’s a system for the absolute elimination of waste.”

Some people imagine that Toyota has put on a smart new set of clothes, the kanban system, so they go out and purchase the same outfit and try it on. They quickly discover that they are much too fat to wear it! They must eliminate waste and make fundamental improvements in their production systems before techniques like kanban can be of any help. The Toyota production system is 80 percent waste elimination, 15 percent production system, and only 5 percent kanban.

This confusion stems from a misunderstanding of the relationship between basic principles of production at Toyota and kanban as a technique to help implement those principles.

– Shigeo Shingo, A Study of the Toyota Production System

Comments (1)

Print This Post Print This Post

Email This Post Email This Post


2004 essay: Lean Team Software Process

I wrote quite a lot of material about Lean software development from 2003-2005, while I was still at Microsoft.  Some of that was published inside Microsoft, but none of it externally.  This is one example.  Some parts appear unfinished, but I left it as-is.

:Summary: Analyze, design, construct, integrate, verify, and deliver one feature at a time until the customer stops asking for features.

Don’t treat software like a product

How do you measure software value?  Traditional methods treat software like a manufactured product, as if it were an automobile or a toaster, delivered in one big chunk, maybe with a few optional features.  But is that accurate?  How many features of Word do you use in any session?  How many features will you ever use?  And why do you have to pay for all of those features that you will never use?  No, the product view of software is not all that helpful, and it forces consumers and providers into an adversarial contract negotiation relationship where the customer must either specify exactly what he wants in advance, or must accept whatever the producer is offering in large monolithic units.

An alternate metaphor for software value is a refined substance, like gasoline or ice cream.  The raw material is customer requirements, domain knowledge, time, and energy; and this is transformed into manifest behavior of a computing system.  This view suggests that software has no more customer value than the sum of the scenarios that it supports.  Then there is no bright line that defines “complete”, there is only relatively more or less value delivered.  When I fill up at the gas station, I need more than one gallon and less than 100 gallons, and when the pump tells me I have enough, I expect to pay the exact value of the utility I expect to receive from the product.  Software can be delivered in this way: keep giving me more until I have enough, then stop and charge me for what I have consumed.

Or it could be like telephone service: I don’t know how much I’ll use, but there’s a range that I’ll probably keep to.  I don’t know when I’ll ask for service, but when I do, I have some expectations of the performance of the service.  We agree that you will supply me with on-demand service at a guaranteed level of performance, and I will pay a fee for that service.  Maybe that fee is pay-as-you-go, and maybe it’s a subscription.  I expect you to give me either option.

Software should be the same way.  I don’t want to tell you what I want the software to do.  I want to tell you what I want to do right now, and then I want you to enable that as quickly as possible in a way that is least distracting to me.  I don’t want to specify what I might want to do next year.  I’ll figure that out next year, and then will I expect you to enable that as quickly as possible.  As the relationship matures, you may start to anticipate what sort of things I might want, and then suggest them at an appropriate time in a way that is not annoying.  Sometimes, I might like your suggestion and then ask you to deliver that, but you had better not burden me with the cost of your attempts to anticipate my wishes.

Ironically, Lean Manufacturing treats manufacturing production more like a fluid, with streams and flows.  If we want to consider software value to be more fluid, then perhaps Lean can supply us with the right concepts and terminology to enable that mode of production.  A suitable name for such a solution might be Feature Factory.


Q: How do you deliver value to a customer when the customer doesn’t know exactly what he wants, and you don’t know exactly how to build it?  (see Five Orders of Ignorance)

Q: How do you avoid delivering features that the customer doesn’t really need or want?

A:  Continuous delivery.  Analyze, design, construct, integrate, verify, and deliver one feature at a time until the customer stops asking for features.

How might the Team Software Process apply to this solution?

The advantage of the Team Software Process is the high quality of the code it produces.  How much of the Team Software Process can be applied to such a demand-driven model?  How much of TSP actually depends on batching and queueing feature requests by workflow phase?

Start with TSP as defined, eliminate non-value-add work products, and eliminate gaps in value streams.

[TSP exchanges one type of waste, defects, for another, copious bureaucracy. ]

To eliminate gaps in value streams, we might:

* integrate phases into workflows everywhere possible
* compress non-integrated phases
* substitute short, fixed-length iterations for long, fixed-scope iterations
* substitute feature-oriented task scheduling for component-oriented
* substitute feature-oriented proxy estimation for component-oriented
* implement continuous flow of customer-valued features to production code
* integrate security and reliability analysis into value stream
* implement pipelined continuous integration

To eliminate non-value-add work products, we might:

* substitute measurement for estimation
* implement numerical specification of requirements
* substitute executable tests for requirements documentation
* substitute executable tests or automated design analysis for design documentation

This looks like a lot of change.  However, the core workflow of TSP, as represented by the process scripts, remains largely intact.  There are a few minor changes in workflow steps, but most of the changes are in sequencing.

step 1: reduce TSP iteration scope to a single feature
step 2: factor tactical vs stratgic planning decisions, and assign strategic planning to a new fixed-duration replanning iteration
step 3: optimize single-feature workflow according to the opportunities created by the dramatically reduced scope

Can this still be considered TSP?

Well, I’m not particularly interested in labels, and the customer probably isn’t either.  How many customers actually care about your ISO9000 certification, if it even means anything at all? TSP is a means to an end.  The customer’s end is high-quality product, where quality is defined only in the customer’s terms.  The customer’s terms likely do not include any notion of defects-per-KLOC.  The producer’s end is profit and reputation, which comes from managing cost and consistency.  If TSP, or something related to it, helps us realize our ends, then (and only then) it is meaningful.

Comments (4)

Print This Post Print This Post

Email This Post Email This Post


E-mail It
Socialized through Gregarious 42