Charting team course with a Seamap

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.