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 http://blog.cutter.com/2012/09/05/pursuing-velocity/ 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.

John Heintz co-presenting at Agile Roots 2010

John Heintz will be co-presenting with Israel Gat on Toxic Code.

I’m very excited, both to be presenting with Israel Gat (The Agile Executive) and to be going to Agile Roots this year!

We’ll be presenting on Toxic Code. This is a topic that I spent a lot of time on last year, working with a client to re-architect a system from the inside out while it was running in production.

Here’s the abstract of the session:

Technical debt had originally been conceived as an expediency measure – “a little debt speeds development so long as it is paid back promptly with a rewrite.” However, like financial debt, unrestrained borrowing can lead to a broad spectrum of difficulties, from collapsed roadmaps to inability to respond to customer problems in a timely manner, and anything in between.

Recent advances in source code analysis enable us to quantify technical debt and express it in $$ terms. By so doing, the software development process can be governed with unprecedented effectiveness. It is possible to constrain the “development on margin” mal-practice and avoid the toxic code phenomenon: technical-debt-to-value ratio of 100%. Moreover, even toxic code can ultimately be “marked-to-market” by reducing/eliminating technical debt.

The combination of Agile refactoring practices with technical debt analytics brings rigor to the software development process through:

  • Providing quantifiable data about the overall state of the code and its value
  • Driving the refactoring carried out through the Agile process from a risk mitigation perspective
  • Balancing the technical debt work stream vis-a-vis other work streams

In the course of managing software development in this manner, your team will improve its design, coding, testing and project management skills. Ultimately, these improvements are the best antidote against accrual of technical debt in the future.