The Outbox: An EIP Pattern

The Outbox

The outbox pattern, I believe, is missing from the Enterprise Integration Patterns book. This pattern is exactly like the local outbox that email clients have for disconnected operation.

How can producers reliably send messages when the broker/consumer is unavailable?

The producer of messages can durably store those messages in a local outbox before sending to a Message Endpoint. The durable local storage may be implemented in the Message Channel directly, especially when combined with Idempotent Messages.

This pattern is implied in the book inside the Guaranteed Messaging pattern. See the “Computer 1 Disk” inside the image.

This pattern avoids the following [The Lost Send]:

  1. Producer sends a message.
  2.  The Message Channel is temporarily unavailable.
  3. Messages will queue locally and periodically retry sending.

This pattern can be used to minimize [The Premature Send]:

  1. Producer sends a message within the context of some local processing scope or transactional boundary.
  2. After sending the message, but still within the same processing scope, the producer aborts and rolls back local changes.
  3. The message may already have been sent and processed.
  4. Either:
      1. The Producer can send another compensation message to undo actions,
      2. or the producer can first store messages in the Outbox and then at the end of the scope push or purge local messages.


Don’t Blame the Capital Letters

After seeing several references to a blog post [1] attacking DevOps as the cause of harm. This morning I saw it again and quipped:

Examples of capital letter branded ideas/processes/frameworks that I’ve personally seen blamed for all manner of ills include Agile, Lean, DevOps, Six Sigma, DevOps, Flat and Hierarchical Org Structures, and Waterfall. However, all of these are simply “thinking tools” that can be used for good or evil. I reject that these tools can be the underlying cause of any of these ills.

(I don’t even blame Waterfall for many of the death marches in its wake. Waterfall is _supposed_ to have feedback loops and we should collectively re-examine a plan that isn’t working. Waterfall isn’t ignoring those things, project leaders and management are!)

Instead, we should look towards essential aspects of human nature: trust, collaboration, purpose, autonomy, safety, thinking about the future, honesty, value, growth, learning, and any others that affect how we socially interact.

[1] The topic is DevOps and the post is here: and I can certainly sympathize with some of the pains and failings written there.

Keynote at the Lean India Summit 2013, Work Visualization

At the Lean India Summit 2013 conference in Bangalore I gave the following keynote presentation:

In this presentation I describe various techniques I’ve used that have been useful for helping individuals and teams see, manage, and accomplish work.

  • Personal Kanban for individuals
  • Team Kanban boards for team collaboration
  • Multi-team coordination and Release Planning for streams of parallel work
  • Program modeling to tie threads together
  • Multi-Layer Roadmapping for long term collaborative planning

Please comment on other styles of visualization that have worked for you!

The User Story, an elegant requirement

As a product manager, I want to better understand and articulate requirements so that I can more effectively guide development to create value.

Agile User Stories have become the lingua franca of all agile requirements, and this simple construct is an incredibly effective way to encode and share requirements.

This one little sentence contains the answers to the most powerful questions of value creation and product management:

Who, What, Why

Here’s the story format again:

As a <who>, I want <what>, because <why>.

Notice, crucially, we don’t have How. That is never part of a user story. The user doesn’t care how, and it’s premature to start specifying it in this requirement.

Finally, I want to comment that if you’ve written the Why and you haven’t rewritten the Who and the What… then I recommend you take another look.

Video: Sequential and Collaborative Planning

This is the first video in a new series, Gist Labs’ Experiments in Video.

I’m very happy to be joined by my friend Matt Roberts. Matt is a Senior Director of Software Engineering at CA Technologies and someone I respect as a true leader in addition to being a manager.

The topic for this cast is planning models, and how to arrange a plan either fundamentally in sequence or as a collaboration. This diagrams are essentially the same pictures I’ve drawn on dozens of white boards. Whether it’s work with teams struggling to get done-done within a sprint or programs struggling with cross-team dependencies, the picture is the same every time.

Please watch this short (less than 9 minute) video, share it with those who plan work for themselves or others, and comment on what you like or dislike about these ideas!

(Update: Different link… now with louder volume.)

Visualizing Work

Work can be hard enough, it doesn’t need to be invisible!

NOTE: Please fill out the “contact us” form on the right, or just leave a comment asking, if you’d like to be notified when the future webinar series on this topic is scheduled.

Here is a selection of visualizations that I find very helpful when managing work, either my own work or an organization’s work with 22 teams.


Roadmap connect multiple high-level threads together over many quarters or years. They answer the questions of Who, When, How Often, What, Why, and How. Some can be sparse and others very (over) loaded. Here is a quarter of a year long roadmap that shows the various connected teams and how their work is connected:

Multi-Level Roadmap with connected work

This roadmap exposes the actual complexity of the current work management system.

Program Management

A program is a work managed towards a specific goal. Programs are larger than any one team and take longer than any near-term planning horizon. Here is a small visualization of a program from an unreleased tool. Work is pulled from the right, always completing towards the valuable goal on the left.

Screen Shot 2013-04-23 at 4.26.34 PM

A program of work is more structured than just a list of items, as an Agile backlog often is. Often, a program makes an excellent wrapper around the bulk of the agile backlog. programs tend to important integration milestones and reviews that provide a natural tightening shape.

Agile Release (Quarterly) Plans

Agile “release” planning covers the scope of multiple sprints. I usually suggest quarterly planning but this could be anything from one to six months. This planning does need to include multiple sprint ahead, in order to gain the benefit of coordinating dependencies across teams (or dependencies will become unplanned interruptions).

First, we see a multi-team release plan based on sequential dependencies. Here a project or program named “A” is works on by several teams.



This sequential style of work management has the disadvantages that the plan must be “right” and any delays can cause havoc at the end of the timeframe.

Next, we see a multi-team collaborative model for work management. In this case teams are working directly together at various times to collaborate on the work.


Notice in this more collaborative style that there are fewer elements to manage. This is actually a simpler way to manage work, but the actual collaborative activity will be highly messy and fast-paced.

Personal and Team Work

Visual Boards have long been useful for individual and team work. Here is the simplest example, showing Ready-InProgress-Done designations for work.

Tempest - Kanban2

Here is another example, with both more states for work to move through (columns) and more specific routes that work can travel (rows).

Kanban UX in Pod 2

These more details work management boards have two key values:

  1. They show what is actually happening now
  2. They indicate what you should do next

Something these boards don’t do well is provide the connection to the big picture. There are some variations on these (called 2-tier kanban boards) that show one level up, but this doesn’t give enough visibility when we are working on a single activity for a program or roadmap level goal.

Common Abstractions

All of these visualizations have a few things in common.

  • They use space and structure, and sometimes lines, to indicate meaning and relationships
  • They have a direction, work is either approach from left (time) or right (priority)

SPOOn Framework: Context and Consequence

tl;dr; We often spend too much time myopically focused on the processes and direct outputs of our work. We must remind ourselves to see the whole by examining the structures (context) that constrain our work and its outcomes (consequences).

In my consulting work over the past few years, I’ve had the privilege of working with many colleagues, and sometimes I get to blend ideas together in ways that seem to capture a simplicity and general application. One such blending is SPOOn, which combines the Structure-Process-Outcome framework from Luke Hohmann with the Process-Output-Outcome framework from Israel Gat. See Luke’s book “Journey of the Software Professional” and Israel’s post for references.

SPOOn Framework

The Structure/Process/Output/Outcome-name (SPOOn) is my combination of these two excellent thinking frameworks. I’m referring to this as “spoon” because it is easy to say and because I can refer to the comic superhero The Tick  ;)

Why these frameworks?

We spend much of our time, energy, and words on the processes we are engaged in and the direct outputs of these processes. These frequently discussed parts of the whole:

  • Agile methods and code, velocity, cycle times
  • Creative/collaborative processes and ideas generated
  • Training processes and certifications
  • Business alignment processes and scorecards

In fact, we spend so much time wrestling with these topics that we often ignore the bigger picture. What context (structure) is constraining the execution of this process or defining the output? Do the outputs actually make a positive difference in the overall result (outcome)? These questions are much, much more important than trying harder to adhere to the letter of some process or squeeze one more ounce of efficiently into an output.


From Luke Hohmann’s book, I’ve clearly understood that every process exists within some structure. The structure both supports and constrains our activities. Structures can be in our head (mental models and world views) or baked into our organizations (yearly financials, hierarchical reporting, delay penalty clauses). Some structures that affect our team processes (like Agile or Lean) include the trust/respect relationship our manager has with his or her own peers. Another is the contract we have with our VIP client.  Yet another is the architecture of our product.

Structures can possibly be changed … but over time and with effort. (Structure/Process/Outcome also includes feedback loops not shown here.) It is certainly true that we must begin by succeeding within the existing structures and not simply try to change them, even for very good reasons. It is also crucial to understand that structures exist for a reason and they evolved that way. As Jerry Weinburg says, “Things are the way they are because they got that way.”

Every process must exist and succeed within the structures that constrain it. Forgetting that, or merely denying it until too late, can lead to the feel and appearance of success until things start to fall apart. For example, Agile pilot teams can thrive right up until the moment when the rest of the organization is supposed to adopt the new code and new way of doing things. The existing structures have been either tolerating, misunderstanding, or undercutting the new process and simply aren’t ready to absorb change that goes against their grain.

How do structures constrain processes and outcomes? Here’s another example: imagine being lost in a city. The approaches (processes) available to find your way in this situation are constrained by the structure around this circumstance. Are you on vacation or almost late for an appointment? Is wandering around an adventure or a source of anxiety for you? These internal and external structures will affect how you choose to proceed and judge a valid outcome.

SPO Framework

Output vs. Outcome

Our processes are like little engines that produces stuff. Sometime they do this more or less reliably… but still we go through some actions and have something to show for it. If we only focus on this very direct output of a process, then we can easily miss the connection with everything else downstream from that process — the rest of the system. Israel Gat has created a model that distinguished the output of a process from the outcomes that result.


The Structure/Process/Outcome [KMP1] framework uses the name “outcome[KMP2] ” for both the immediate and secondary results of a process. From Israel’s and my own experience, I find that distinguishing more clearly between output (first-order) and outcome (second-order or systemic) results provides much more understanding and insight into what is really happening and why. In fact, it helps change people’s perspective.

As an example[KMP3] , consider an Agile team delivering stories at the end of a sprint. If the direct output of “accepted stories” is the only measure paid heed[KMP4]  by the team or management, then they will simply apply pressure to work harder, faster, longer … to get more stories finished. Teams can certainly find ways to deliver what is measured and increase the output of accepted stories. Two common secondary outcomes for this circumstance are: 1) the team works overtime[KMP5]  and ends up creating more bugs; or 2) a more reasonable team only works on new stories and doesn’t spend enough time learning and exploring. This second outcome is more delayed and harder to see than the first, but it still has  a big impact in a competitive and changing landscape.

These examples highlight two important characteristics that separate outputs from outcomes:

  1. Outcomes don’t happen “right now”
  2. Outcomes don’t happen “right here”

Both of these fit squarely in what systems theory calls “delayed feedback.” If you’ve ever first scalded then frozen yourself in a shower… well, you’ve already experienced this. Humans are really[KMP6]  bad at determining cause and effect when delayed feedback is present, and any help we can get in seeing this bigger picture is useful.

Outcome is much more important than output. We seldom measure and reward for it, but that is exactly what we should do. Focusing on the outcome [KMP7] gives us both a better measure of success and more freedom to experiment and improve our processes and outputs.

This post is intended to help us better understand where we are right now, to more clearly see the full picture[KMP8] . Future posts will examine how and why we change our systems by digging deeper into feedback loops, values, and vision.

Note: Private correspondance with both Luke and Israel has turned up essentially the same next thought on scaling these ideas up: expanding and integrating. From Luke the suggestion is multiple interlocked Structure/Process/Outcome frameworks. From Israel the suggestion is shifting focus to integrating across the entire life cycle of a system.