Horizonal goals

Video version here

There’s this great, short book by John Kay called Obliquity. It’s about goals that you can’t achieve by aiming for them directly; you have to look for an oblique goal that will happen to get you there. Like, you can’t aim for “happiness;” you have to find something such that aiming for it makes you happy, like raising children or writing or helping people who are hurting.

This book gives a name to some parts of my seamaps. The star at the top is the “high-level objective,” the unquantifiable goal which can never be achieved. Aiming for it sends us in a direction which happens to obliquely fill a goal such as “happiness” or “profit.” Goals such as “change the way development is done” or “find the optimal combination of music and words” or “address the observability needs of modern architectures” These are horizonal goals; as we make progress, the state of the art moves. We can never reach the horizon, but aiming for it takes us interesting places.

The mountains in the seamap are milestones. They’re achievable, measurable goals that we work toward because they’re in the direction of our high-level objective. Periodically we climb up and look around, take stock of whether our current direction is still going toward our star, and if not, change our milestone goals.

There are many smaller milestones on the way to the bigger one. Each offers an opportunity to take stock and possibly shift direction. There are actions that we take to move toward these goals. This is us in the boat, rowing.

Obliquity adds another element: necessary states. A necessary state to moving toward the next feature is: tests are passing. A necessary state for teamwork is that we are getting along with each other. Many of the actions we take are aimed at maintaining or restoring necessary states. These are like the whirlpools in my seamap; we have to smooth them out before we can row in the direction of our choice.

For example, here is a seamap for my current activity:

high-level objective: change the way people think about programming. Goal: explain Symmathecist. Subgoal: explain Horizonal. Necessary state: don't be too drunk. Action: type this post before opening wine.  

I will now hit “publish” and go open a bottle of wine.

Deliberate impermanence

There’s something magical about post-its falling off walls.

ancient post-its on my own wall

I think about this as my team spends time pruning tickets, closing ones that seemed important at the time, but now aren’t worth doing. These are ideas that need to fall through the cracks, to slide down the wall behind the file cabinet, to let us focus on the few that matter.

Instead we’re spending time and decisionpower on eliminating old ideas. Me, I’d rather dump the lot of them and resurrect the crucial few.

Then consider the connections between tasks: Christian says that before we create this command form, we need the http endpoint story completed. I could set up a relationship between these tickets, we could make a whole diagram and tie our current priorities into a line. Yet, interdependencies change and shift. We switch priorities quickly as we learn about customers.

The tenacious task tracker is stronger that sticky notes. At best, it’s out of date. At worst, it leads to ossification, to attachment to old plans. If it’s too hard to change this tracking…

Wait. I think it’s more than this. “Easy to change” isn’t enough. “Trivial to change” isn’t enough. The post-its fall on the floor, we pick them up, we put them back, “Oh actually this belongs over here. This one doesn’t even matter anymore. Ah, that was done weeks ago.” The wall of stickies requires active maintenance even to stay the same. It naturally degrades. This leaves room for evolution. Every post-it on the floor is an opportunity for a new start.

So we don’t set up dependencies between tasks. We leave those in our heads, or individual notebooks. I put them on seamaps sometimes, which I use to summarize the daily standup; these only last a day.

a standup seamap: bunch of task mountains with lines to each other and the star-goal; people in boats headed toward mountains.

Embrace degradation and dump those piles of precious, stale ideas. Be cautious about weaving tight plans and documenting them: persistence has a hidden price.

Free idea: chaos gnome for task trackers?

Charting team course with a Seamap

(or on video: https://youtu.be/RCrKh3yvJR4)

Great teams are focused on results, not on projects. But how many of us really see the results of our efforts? Can we track the impact of what we’re doing today all the way to its hoped-for impact on customers or users?

A project roadmap doesn’t cut it. It doesn’t give us a compelling picture of what we’re accomplishing. It acts like there is only one path toward our goals. A roadmap fences us in, reduces options, squashes ideas.

We want a visualization that lets us see the business goals, from the customer to the organization to the team to the individual or pair. From ages to iterations to the current day. We want to document our aims at each level, and record our attempts and the problems we faced. We don’t want to restrict ourselves to the first plan someone came up with. We want to reach the right milestones, discard others, learn — all without losing perspective of the larger goals.[2]

Marty Cagan said he knows roadmaps are terrible, but he didn’t suggest an alternative. I have one: it’s called the Seamap.

A seamap represents our journey as a mountain across an ocean. We won’t sail straight for it across the deep water; we’ll stop at many islands along the way. This is iterative delivery. We don’t have to travel in a straight line, because we’re exploring the solution along the way. Islands we thought we would visit may become less interesting, while new ideas erupt and solidify.

At each milestone in the seamap, we can zoom in. That part of the ocean contains the likely stops on that piece of the journey. Each day, as we discover tasks, we can add that. Achievements can be recorded with little flags. Surprises are represented by a sea monster; we might defeat it, or route around it by accomplishing our day’s objective some other way.

The zoom can go as deep as necessary; milestones we thought were close often are more treacherous than expected. That’s why I use Prezi to create the seamaps: every level of scale is explored in one document.

At the very top, above the horizon, above the highest-level goal, are the Unreachable Stars. These are guiding principles that direct our journey, even though they’re never perfectly achieved. These are the aspects of quality that matter for that project, or ethics that matter to the organization. My projects all include “evidence this will work,” which encompasses market research, proof of correctness, and automated testing. We never have perfect testing, but any task that takes us closer to that star is valuable in more ways than its immediate progress toward a milestone.

On a daily basis, I use the seamap in standup. As each developer or pair states their plans for the day, I place their pictures (trello icons) on the place on the map. We can see whether we’re all spread out, or working closely. Other images mark points of interest: drop monsters into the picture for problems, a sea arch if we plan a nontrivial deploy.[4]

On an iteration basis, as well as anytime I ask myself whether I’m working on the most important thing, I zoom out in the seamap.[1] Then I can ask, is this still the best route to our ultimate goal?

The seamap provides perspective, planning, and task organization. It does not pretend that we already know the single route to our destination. It can show what we have done, where we are now, and where we are going. And, it’s beautiful to look at![3]

Try this on your team: copy this mostly-blank template, or look at other samples on my Prezi profile. If your team is colocated, draw this stuff on a white board or a poster. Draw on post-its, print images and tape them, then move them around the next day. A physical seamap is the best way to find out what works for you. I started with a giant post-it board on my bedroom wall, and held it up in front of the camera for remote stand-ups.

Marty Cagan also said: if your developers are only for code, you’re getting only half their value. We aren’t typists; we’re thinkers. Support and encourage thinking, ideas, innovations by sailing off the roadmap into a world of wider options.

Feedback and suggestions welcome!

[1] Mary Poppendieck says that in the military, one must understand the intent of orders two organizational levels up, and maintain situational awareness (“when something goes wrong, we’ll know in time to do something about it”) one level up.

[2] Drawing a line and sailing straight along it may seem efficient, until the ship sinks in the middle of nowhere. Instead, stop at a port each night (deploy some code), and we have a solid place to come back to.

[3] Somewhere there’s going to be a spreadsheet, or Trello, or Target Process, or Jira, or something containing the nitty-gritty of each milestone and task. Don’t let the linear, one-dimensional format of those limit you. Label or link the seamap images, refer to those more detailed descriptions as needed. Keep upper management happy enough while your team explores and learns.

[4] I use other maps to show tasks like firefighting and hardening of the current system. These are based around data flow in the existing system, typically. That’s another blog post.