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.

Structure

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.

Time_to_Market_as_an_Outcome-500x347

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.

Business: Knowledge, Risk, and Customer Value

What do knowledge, risk management, and customer value have in common? Only your business value, and here’s what it looks like:

Everything you do in a commercial sense has an effect on one or more of these three variables. Here are some examples:

  • Bring customers together and discover[1] what they need and desire => will increase Knowledge
  • Build some Architectural Runway => will decrease Risk
  • Improve a frequently used feature => will increase Customer Value ($$)

But there are some actions that can move more than one variable at the same time, consider:

  • A/B testing two features and releasing the winner => will both increase Knowledge and Customer Value
  • Address site stability/performance issues => will reduce Risk and increase Customer Value

This chart provides a way to prioritize an organization’s backlog of work by asking the following questions:

  1. What are the current values for Knowledge, Risk, and Customer Value?
  2. Which way are they heading? 
  3. What ought they be?
  4. What next steps will bring me closer to what ought be?

Alistair Cockburn has been explicitly modeling Knowledge for years, and in fact his writings considerably influenced my thinking on these three variables. See Alistair’s Knowledge Acquisition Curve for more details. Very recently David Anderson has reframed Kanban as a Knowledge Discovery Process.

Risk Management is an extremely underused tool. Usually someone, somewhere, just decides arbitrarily what should or shouldn’t be done.

Customer Value is the important to everyone, but in Agile Scrum projects it’s especially the the Product Owner who is responsible for growing that curve.


[1] Consider playing “serious games”, see Innovation Games