Monthly Archives: April 2013

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:

They show what is actually happening now

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)

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.

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:

Outcomes don’t happen “right now”

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 is a glue and improvement role… it’s a little difficult to define with bullet list of job requirements. The SM isn’t about scheduling meetings, but actually helping the team get better at those meetings, at delivering and making progress. Often though, scheduling meetings is a useful way to help. Some teams don’t need that help and schedule and prepare for all of the meetings themselves.

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.