Does your IT organization make a practice of yearly roadmapping? Mine does. The current shop, the previous one, the one before that, and on and on. Just about every technology department I’ve been a part of does some form of yearly roadmapping exercise. The one characteristic that they all share? They’re drudgery.
The process of creating a roadmap seems a staple of the yearly business cycle, but that doesn’t mean that it has to suck. I work with technology folks who, independent of the sales pipeline, are asked to list, size and prioritize some set of initiatives that are either wanted (eg. trying out a new language) or needed (eg. addressing tech debt) by the engineering departments. It’s a noble goal, making developers’ lives better by helping them get their environments free of impediments.
Problem is: no one looks forward to the planning sessions. When I try to recruit participants (usually a subset of architects, team leads, etc.) for a roadmap planning session, everyone spontaneously seizes up and/or runs from the room.
When my boss asked me to coordinate this latest series of roadmap discovery and prioritization, I replaced the standard “sit around the table and gripe” sessions with two alternatives: Lean Coffee and Six Thinking Hats.
I invited the team to what I called a “planning coffee”, and curiosity took over. When the dozen-or-so members arrived, they saw an inviting table with index cards, markers and coffee carafes (optional). We made chit chat until enough people were there to begin (we did not wait for or worry about the stragglers). A quick explanation of the coffee rules, and we were off writing our wishlist items onto 3×5 cards. People got out of their chairs – their brains getting more oxygen than when they all just sit around – and the mood remained light.
Affinity mapping the cards is a fantastic cue for glimpsing the importance of a topic, but we still did some dot-voting after each topic card (or group of cards) was summarized. If we ended the meeting at this point, we would’ve already collected more information transparently and asynchronously in under ten minutes than we could have hoped for in a two-hour session going around the table with each representative speaking up in turn. Still, we played out the hour-long event asking questions of and examining the top few topics.
After the “meeting”, I took these data (topics cards, votes, added explanations) and compiled them onto a shared document. Others people throughout Engineering were free to read this and add or update as they like. Visibility makes the process much easier.
For the next round (with roadmapping, there’s always a next round) I brought together the whole department in a large open space with no tables. On the walls I’d hung 14 easel-pad sheets of paper – eight representing the top eight issues that came out of the prior “planning coffee”, and one poster of each of DeBono’s Six Thinking Hats. After quick explanation of the goal (to add ideas & insights to the list of prioritized roadmap items), we had everyone form groups (counting off 1 thru 8 helped randomize & balance the teams) and move to one of the eight stations.
Each team spent about five minutes at each station, working through each of the six hats at every stop. They recorded their ideas onto the large paper with markers, then moved on to the next topic paper. At the end of the session, we had fantastic data and suggestions on every one of our top eight roadmap items.
The Six Hats exercise added greater dimension to the department’s wishlist than a room full of mandatory attendees ever could have. The CTO appreciated that the entire exercise was kept to two one-hour meetings (as opposed to multiple days spread out over a few weeks), and she knows that the department “owns” (has defined and is accountable for) this list. It makes her job of negotiating with other management much easier.
