May 2008

APLN Seattle Leadership Summit

I’ll be facilitating a workshop on kanban systems at the APLN Leadership Summit in Seattle on July 17-18. Early registration is open now for the discounted price of $300.

There is going to be a great set of think tank/workshops on hot topics in Agile managment including Innovation Games, Real Options, User Experience, Agile Contracts, and Pull Systems. I’m actually bummed that I’m hosting my own, ’cause I’d like to join in on some of the others!

So, please come on out and join us. Seattle is beautiful in the summer, and it will be a great opportunity to collaborate with innovative thinkers and catch up on some hot trends in software development.

Comments (0)

Print This Post Print This Post

Email This Post Email This Post


Coffee cup kanban

Coffee bars employ a couple of different strategies for taking and filling orders. Each strategy makes different tradeoffs.

Sometimes someone will take your order, ring you up, and then make your drink and give it to you. Other times someone will take your order, mark up a cup with the details of your order, place the cup in a queue to be picked up by a barista who will make the drink and then place it on a shelf and call it out.

That second arrangement is a kanban system, and the cup is the kanban. The cup-ban doubles as an order form that can encode most combinations that a barista should expect.

There are reasons to choose one process over another. The first method is usually applied by small or lower-volume shops with only one employee on shift. The second method is usually applied in larger, higher-volume stores with two or more workers on shift. An advantage to the store of using the kanban method is that they can take your order–and collect your money–quickly. Unfortunately for you, that often means exiting one queue so you can line up in another, more captive queue.

It’s good news for you when the barista asks you, “can I get a drink started for you?” because that should mean he has slack capacity. By the time the cashier finishes collecting your money, the drink should already be under construction. The barista shouldn’t ask you that if he already has a queue of cups to process. On the contrary, once the kanban queue starts backing up, the cashier should start stalling, even if that appears to make the cashier queue back up. The second queue has limited capacity before waiting customers start crowding each other or irritating seated customers.

Some shops get obnoxiously long lines during the morning rush. The solution to that is usually adding an additional espresso machine. The complicating factor is that the rushes don’t last, and then the surplus capacity goes unutilized for most of the day. Still, I know for certain that some shops lose sales, and even customers because of the lines, so I don’t think that strategy is employed as often as it should be.

Watch your coffee cup once your order is taken. It should never stop flowing. If it does, you should ask yourself why and imagine what you might do differently.

Comments (9)

Print This Post Print This Post

Email This Post Email This Post


Boehm’s Spiral Revisited

Twenty years ago this month, in response to the problems associated with waterfall-style approaches to software projects,

Barry Boehm proposed his Spiral Model of Software Development.

Which bore some resemblance to Deming’s “Plan, Do, Check, Act” cycle.

Boehm’s insights have had a huge positive impact on how we think about software development. But the spiral itself lost some of the beauty of Deming’s model: the simplicity, self-similarity at different scales, and the balance between activities in the quadrants. Which, perhaps, has caused Boehm’s model to be underused as a tool for introducing people to how creative engineering works. This is unfortunate, because the waterfall model, being more obvious, continues to be where most people start. Only then, after they have personally experienced the pain of struggling projects, do they search for a more appropriate model.

The Simple Sprial

Here is a simple love-child between Boehm’s and Deming’s views which has been very helpful to me in keeping a visual model in mind when thinking about how effective software development (or any creative engineering) really works.

Customer Plan
Test Design

How does this work?

  • The more iterative your development process, the more times you spiral around
  • You spiral inward from the high-level descriptions down to the lower level implementation details (note: this directionality is inverted from Boehm – this model doesn’t try to convey the amount of cost or work in each loop around the spiral)
  • As you spiral down, the activities change. “Design” at the high level might be on paper. But as you spiral down, design is about turning those paper documents into executable code. Same for the other quadrants.


  • Customer. What does the customer think? In one of the better trends of the last 20 years since Boehm’s paper, agile methodologies have recognized the customer as an essential direct participant of the development process. We can try to guess what the customer ultimately will find valuable. But if we don’t regularly check back with them, we’ll get enough wrong to sink our product and company over time.
  • Plan. What do we plan to do? This includes requirements analysis, priorities, risks, and schedules. At the very high level, it may be corporate goals. At the very low level, it might be writing an automated functional test before writing the code to make that test pass.
  • Design. How will we do it? At the high level, design is done via documents, diagrams, and discussion. At the lowest level, design is expressed as the executable code that constitutes the product.
  • Test. Have we done it right? At the high level, we discuss and review ideas and documents. At the lowest level, we execute tests against the functioning product.

The four quadrants align with how we tend to specialize our people and organizations as we grow. In a Microsoft organizational model, it aligns with customer, program management, development, and test.

The “Simplistic Spiral”

The simple spiral is useful, because it is flexible enough to encompass many approaches to development. Take the waterfall model from the top of this post, and wrap it into one loop through the spiral, and you get “the simplistic spiral.”

Customer Plan
Test Design

Wouldn’t it be nice if projects could reliably just work this way?

But we know if we apply this model to a large product, we’re nearly certain to have a disaster on our hands where many assumptions made in planning are discovered to be poor in design or test.

But apply it to a queue of appropriately-sized (small) and well-understood functional requests, and it may be an appropriate model for each kanban in a lean production workflow (or perhaps each kanban should be two or more loops round the spiral). In any case, the model is helpful in visualizing all these cases.

The “Product Spiral”

It also helps us create useful visualization of product lifecycle models at various scales.


At the company level, we are constantly cycling: seeing what the customer/market reaction is to our products, planning new products and enhancements, designing and testing them.

At the product level, it’s the same, but from the perspective of the evolution over a lifecycle. But even when a product enters later lifecycle phases like maintainence, the model is still the same: the customer finds bugs, we prioritize, fix, and test them — and it goes back to the customer for the cycle to start again.

At the feature level, we recognize that this has a lifecycle of its own. Before committing a feature to a product, all aspects (including feedback from the customer) should be covered, likely with several iterations. Perhaps one of the secrets of success to many open source ecosystems is that they encourage/allow individual features to evolve independently and iteratively, before committing to integrate them.

At the change level, we have gotten the granularity small enough that each change may appear to be its own mini-waterfall of plan, design, and test. But even that is a simplification — chances are, the person making the change looped through many interrelated planning, design, and test alternatives in their head before committing the change.


In future posts, we’ll apply this model to take a look at other aspects of the engineering process.

So — is this a useful model for thinking about engineering, particularly software? Or is this model dangerously simplistic for helping to think about how your organization works?

Comments (2)

Print This Post Print This Post

Email This Post Email This Post


E-mail It
Socialized through Gregarious 42