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:

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.

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.

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

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)

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.

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.

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.

The SM doesn’t have the answers (to technical questions or how the team should organize). These answers are for the team to self-organize and figure out. But, the SM should have the right (and sometimes tough) questions that are important to ask. This requires a tremendous level of insight into the whole team, the individuals of the team, and the work.

Facilitate: to make easier, help bring about, Merriam-Webster

The definition of SM I use now is: ”To continuously help make easier the teams execution”.

Notice I don’t say how to do this… that’s the trick the SM needs to figure out. Maybe the team needs more story definition, maybe less. Maybe it’s the team needs to learn more frequently, maybe the team is spending too much time in “discovery”.

It is the whole team (the PO, SM, and developer/contributors) that make a prediction/commitment. The PO is focussed on who/what/why both on the horizon and articulating these to the team during sprints. The developer/contributors are focused on the how, right now and with an eye towards the future. The SM is keeping the focus and momentum aligned, within and outside the team, to enable continuous improvement.

Who’s responsible for execution? In Scrum the PO is ultimately responsible for the value delivered, by being responsible for the definition of the work and prioritizing is effectively. The team makes commitments (now called predictions) together. The SM isn’t responsible for “delivering”, but rather for enabling. The SM doesn’t have the authority to command, but must balance and negotiate.

Here is how I would distinguish the role of SM in a few examples:

1) Ensures the team is ready for the meetings, and the team is setup for success in the meeting.

The SM helps to ensure both the PO and the developers/contributors are ready for meetings. This can be a gently reminder or canceling a planning meeting if the PO and/or team aren’t actually ready. During the meeting the SM is helping to make sure the whole team is clear what’s being asked and what decisions are being made, this is the who/what/why/how questions. If something isn’t going quite right (i.e. a Story that isn’t clear enough) then it’s the SM who usually suggests that it be taken out for future review.

2) Tracks and manages the resolution of an issue (like a problem implementing a story).

When something is going awry, it’s the SM that either tracks it or the SM works with a team member who is primary on the issue. The SM should know about all of the issues that are either a) touching outside of the team, b) involve communication with the PO, and c) are internal to team but serious enough to risk a sprint deliverable. Also, the SM should be able to effectively discuss the issue with either the PO or the team – most of the time being able to represent either if the full group can’t talk.

3) Team retrospective and improvement.

During the retrospective it is the SM who sets up the right questions to ask the team so that they can learn the most from the reflection. I call this “holding a mirror” up to the team. This is an example of the SM not having answers… but rather the hard questions. An example might be (relative to a story that was really hard to finish) “Isn’t this the third story in that subsystem that we’ve struggled with?”, or perhaps “Should we review and estimate <future story> because it seems similar to this tough one?”, and then “What should we start doing to help avoid this type of problem in the future?”.

What if the team is failing to deliver? I’d ask the SM what is going on, and I’d expect them to have an answer (at least partial). Then I’d ask the SM what we should do about it (a plan for change that addresses the situation). That plan might not be a solution to deliver everything asked up front, but it should be based on the reality of the team and context. The SM might recommend the team should work on cross-training more, or increase work on test automations, collaborate with another team more, or possibly recommend individuals be removed from the team. The SM would work first to help the team get more reliable/predictable, and them help to enable the team to go faster easier.

• Somebody talks way too much
• Somebody doesn’t talk or contribute at all
• Arguments of being “right” and convincing others
• Problem solving starts (prematurely)

Here is a set of rules that can be called into a collaborative meeting when five or ten minutes of progress needs to occur without these delays.

Rules for Fast Collaboration

1) Take turns

Round-robin works well, just make it clear and fair.

2) Do one thing

Add a post-it, draw a line, move a card, remove something, or maybe reorganize a few together. Pick one of those and then be done.

3) Explain your action

“I <something> because <thinking>“. Don’t argue or convince, just explain.

Their exists a wonderful library to do this (mechanize) implemented in Perl, Python, and Ruby. But we were writing a Java/Android client, so we did something about it.

Today we are happy to announce the availability of a Java port of this great tool. If you are building a REST client or screen scraping web pages in Java, please check it out!

Here is the project page: mechanize for java

What does this picture mean?

Seems pretty good, right? Work is getting done, pretty close to the ideal line. Nothing to fret over, especially if the mood of the team is good.

Now, consider this alternate view of the same team, same sprint:

We’re about to start the eighth day of a ten day sprint… now it looks like panic. At least a few story points are done-done… but clearly the team hasn’t actually finished much of the work in the sprint. Will it all get done? Will it all get done? Are we looking at a mini-death march?

How could there be such a mismatch, and what can we do about it?!?

Advice: Ignore hours

A team I was coaching was really struggling to complete stories at the end of the sprint. They were being very diligent, but no matter “hard” they tried it didn’t change the emergency they experienced at the end of every sprint. In particular, they tried harder to get better at estimating task hours and making sure to level everyone’s hours….

I became clued into all of this when I was asked: “John, do you think 6 hours per day is reasonable?” This was a sure indicator that the team was missing the forrest for the trees – loading individuals with tasks/hours at the expense of a team getting work done. This was setting each individual up for failure: either I can help my colleague/friend… or I work on what I committed to doing! I don’t like no win situations, especially when it hurts people.

My advice was simple. Just for one sprint, try the following:

• ignore hours, don’t estimate or track then
• focus on the stories, which one is highest priority
• encourage the team to work together in every way that makes sense
• track story point burn down

The team did this, and the result was amazing. Everyone felt free to collaborate and the stories were completed more smoothly. This team did reintroduce some hours back into their process, but they had changed: collaboration and value over hours and tasks.

Note on Kanban: As an interesting note, today most Kanban teams don’t bother with hours, and also don’t estimate stories! (They do often group by size.. so there is still some judgement of effort.) These teams track only cycle time (from start to end) of stories on the board. This gives the same focus on collaboration over hours tracking that I suggest in this post.

Slides are attached to this post, and these are the GitHub repos:

• https://github.com/jheintz/sample-hadoop-testing
• https://github.com/jheintz/sample-riak-testing
• https://github.com/jheintz/riak-download

Here are the scripts that demonstrate everything:

Hadoop Sample:

#/bin/sh

git clone https://github.com/jheintz/sample-hadoop-testing.git
cd sample-hadoop-testing.git

git checkout step1 # initial MRUnit tests
mvn test
# eclipse: show mapper
# eclipse: show reducer
# eclipse: show unit test
# eclipse: try open hadoop source…

git checkout step2 # Use Cloudera repo for sources
mvn test
# eclipse show pom
# eclipse: open hadoop source

git checkout step3 # parameterized many tests
# eclipse test ManyWordCountTest.java

git checkout step4 # parameterized non-mr tests for speed
# eclipse test ManyWordTest

git checkout step5 # add cluster test
# eclipse show HadoopClusterBase
# eclipse test ClusterTest

git checkout step6 # add parameterized cluster test
# eclipse test MultipleClusterTest

git checkout step7 # split unit and integration tests
# eclipse show test names
# eclipse show pom failsafe
mvn test
mvn verify

Riak Sample:

#/bin/sh

git clone https://github.com/jheintz/sample-riak-testing.git
cd sample-riak-testing.git

git checkout step1 # initial test, fails
mvn test
# eclipse show SmokeTest failure

git checkout step2 # add riak downloader
mvn test
# I don’t know why eclipse has maven failure…
# eclipse show riak-build.xml
# eclipse show pom.xml

git checkout step3 # add parameterized many tests
# eclipse show ManySmokeTest

ant -f riak-build.xml stop

Cassandra Sample:

#/bin/sh

git clone http://github.com/jsevellec/cassandra-unit.git
cd cassandra-unit

mvn test
mvn eclipse:eclipse

First, some definitions:

• Abstract: something that concentrates in itself the essential qualities of anything more extensive or more general, or of several things; essence.
• Concrete: pertaining to or concerned with realities or actual instances rather than abstractions
• Precise: definite or exact in statement
• Vague: not clearly or explicitly stated or expressed

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

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.

Yes, you really can

Design your own visual collaboration game

See these Instant Play games for examples you can use right now. Of course Gist Labs can help you facilitate games, and design your own custom games.