A New Problem Solving Technique To Prevent Jumping to Conclusions

The Three-Color Problem Solving Technique

Hide the Blue Markers: A tool you can use to analyze and fix complex problems

You have a problem. It’s a big problem and you’re not exactly sure what it is, much less how to fix it. When you start discussing the problem with your team, you find that some team members are jumping to conclusions and you haven’t even outlined the entire problem.

This is the simplest problem solving tool I’ve used to help a team completely define and analyze a problem before creating any solutions. I discovered this technique by accident, a happy accident. Here’s how it came about.

Hide the Blue Markers: How This Solution Came About

Several years ago, I was working with a team and one day, we started experiencing a production issue. The systems were behaving slowly everywhere: the process queues were backing up; the application servers were nearly idle: the databases were nearly idle; no thread locks or contention could be found. There were many different components and subsystems at play and it was not obvious what was going on. It was quite a mysterious problem.

The team organized into a meeting room to figure out what was going on, what they should do, and I was invited to join them.

Jumping to Solutions

As we dove into the conversation to understand things, I asked the group to step back a moment and draw a systems diagram to show and teach me what was going on – because I didn’t know what was present.

Black Ink One Problem Solving ToolWe used black markers to draw the systems diagram, showing the client components, the communication channels, the various server components and processes and databases and so on.

Use Red Marker to denote problem areasAs we were drawing the systems diagram, we also agreed to use red markers to show the problem areas: where things were going wrong, or where we thought there were risks of failures. As certain risks were marked in red, some individuals would get an “aha” and then jump to leave the room and go fix it.

I literally watched people leap to solutions. I was fascinated.

As the meeting progressed, the team used blue markers to denote solutions. Although I cautioned the team to “not leap to conclusions,” they still did. It was amazing seeing individuals yet again try to jump up and go do something. Yet, we hadn’t even finished fully describing all of the system. And we hadn’t finished describing all of the possible problems, risks, or failures.

One Color at a Time

I began actively facilitating the meeting. I gathered all of the markers in the room and set a meeting rule: “We can’t move on to the next color until we’re finished with the color that we’re on.” That meant that we had to finish using the black marker to define the current systems diagrams and the things that we knew to be true. No more red or blue markers for a while.

Once we all agreed to this new rule, we moved on. We used black until everyone agreed, with a head nod, that we had captured the current system as we knew it. Then, we picked up the red markers and annotated the diagram focusing on the problem areas, where things were going wrong and potential risks. Whenever ideas or solutions came up, we politely deferred those to when we were ready for the final phase: the solutions phase where we would get to use the blue marker.

After the red marker annotations were completed and everyone nodded their heads that we had gotten everything, we moved to the blue marker. We noted ideas, suggestions, things we could try and investigate. And that went on for a short while.

The Full Picture

When we finished this process we had a pretty good view of the whole picture. We understood the components that were there, we understood what all of the possible things were that could be wrong and where they could go wrong, plus, we had a set of suggestions for what we could do about them. It was actually very easy to prioritize what we ought to do next. In fact, some of the suggestions made in blue were quite obvious choices.

At the end of the meeting, we had come to a good decision that worked well for us and we moved on.

Here is an actual first use of this technique (we used BLACK, RED, BLUE marker colors) that the team still talks about helping them not jump to conclusions.
hree color problem solving

Don’t Jump to Conclusions

So, now you know why I call the story “Hide the Blue Markers.” Drawing (literally) conclusions before you’ve really examined the problem is detrimental to your process. I highly recommend using the Three-Color Problem Solving tool when your team has a problem and you can’t figure out the entire problem, nor the entire solution.

How to Hold a Three-Color Problem Solving Session

  1. Grab three colored markers: black, red and green.
  2. Meet at the whiteboard (or use a large piece of paper).
  3. Ask all team members to the join the meeting.

Pen Colors and Their Meaning

  • The black pen is used for diagramming and identifying facts.
  • The red pen is used for identifying challenges or problems.
  • The green pen, however, is used for documenting potential solutions. This is the pen you need to hide. (In my story, “Hide the Blue Markers,” we were using blue rather than green).

The Rules:

  1. Only one color may be used at a time.
  2. You can not move on to the next color until everyone agrees that everything is covered by the first color.
  3. You can return to a previous color if you discover you missed something.

The Process:

  1. Draw in BLACK the things you know for sure. (Systems diagram, current measurements, list of assumptions, …) Keep adding to this until everyone agrees it’s accurate and reasonably complete. Keep asking, “What have we missed?” Get full consensus that all things are drawn in black.
  2. Annotate this diagram with RED for challenges, concerns, or big questions. Keep adding RED until everyone agrees everything is captured. You MAY add more BLACK notes if missing information comes up. NO GREEN may be used at all!
  3. Start annotating GREEN to mark ideas, solutions, and next steps. Do this until everyone agrees everything is captured.

When your diagram is done, you should have a full picture of facts, concerns and possible solutions. From here, you can use a method to sort which solutions should be addressed first. (I’ve used dot voting to great effect).

The Three-Color Problem Solving Tool is an effective technique for helping your team examine a large, complex problem. By hiding the green marker, the one meant for solutions, you will prevent your team members from jumping to conclusions, while helping them completely define and understand the problem before creating solutions.

Please let me know if this technique works for you, or if you’d like some help facilitating it’s use in your organization.

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: https://www.jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/ 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.

Roadmaps

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.

TeamCollaboration

 

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.

TeamConcurrentCollaboration

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)