The best way I could think of writing this was as a dialogue.

The crux here is that backlogs and roadmaps visualized as a series of lists/swim-lanes, potentially obscure something very important.

You need a single prioritized list. There is only one most important thing. And limit work in progress.

No we don’t! Everything “At the Top” is important! Because of that we put them in separate lists, organized by value stream. And then put them on this roadmap that looks like a Gantt chart but isn’t. Limit what we’re working on? That sounds like crazy talk.Cool. So if I pick one of the efforts at random and kill it you’ll be good with that?

Well, I mean, um…I mean if you killed Project Acme Silver Bullet I’m pretty sure our CEO’s head would explode.Like, explode more than if Project Foo Quick Fix was killed?

Yeah. But you know, they’re different. Those two things are both super important, but just…different. His head would explode either way…but explode more with Acme Silver Bullet.Sounds like ASB is more important!

No. But I’ll play along. What difference does it make? We can’t have the whole company work on Project Acme Silver Bullet, can we? Are you telling me we can only do one important thing at once? That is insanity. What would our investors say?So let’s say I’m someone in marketing trying to decide whether to really focus on ASB…or to multi-task? Or better yet, I’m concerned that our customers may have trouble adopting ASB and FQF, and that by rolling out both, we may put BOTH at jeopardy. What should I do?

Hmmm. I’d hope that wouldn’t happen. We have responsible people. I’d expect them to give us some advanced warning. And we both know that marketing CAN’T be our blocker here so…How about your operations team? They’re trying to support both efforts…I’ve seen the tickets in Jira. Right there you paying a fairly significant context switching cost. Juggling multiple efforts like ASB and FQF is like playing 3-dimensional chess.

They need to be more responsible, and manage their projects better! And we need better estimates from everyone, and better planning! Ugh…Ops. What do you expect us to do…have Ops embedded on every team?Like DevOps, for example?

Well played. For real now, we could never afford that! And they’re always dropping some sort of ball, so hiring more seems, um….…Dropping more balls than Sales, Marketing, and Product? Do you measure those? Or are Ops mishaps just more visible and a byproduct of too much work in progress? You might be giving them an unfair shake, though I do acknowledge being overworked makes them grumpy.

About being able to afford DevOps (dedicated Ops)…would it be too expensive if you could have 2x better throughput of your amazing ideas? Imagine how that might change the game!

…but Operations is an operating expense, and our teams are investments in New Stuff! So…But I digress. Sorry about the pontificating. I think what you are actually saying is that as a company it may be important for us to place multiple bets. So it isn’t that the things are more/less valuable, it is that they are different types of bets and should be played a bit differently. “Most important” is a particular type of bet.

I agree with that! But I have to admit something. I think one of the efforts in progress — Project Buying Time — is less important. But we made this promise to this new VP — MustHire BoardMembersFriend — that they’d get a shot, and we had a team — you know, Team Last Year — that was looking for something to do after we killed Project Last Year last year. We don’t want those talented engineers leaving the company…and we don’t want MustHire to leave either.Hmmm. Sounds difficult. From the looks of it though, you aren’t really giving Project Buying Time all the attention it should be getting. How do the engineers (and MustHire) feel about that? What if they pitched in to help on ASB, or to fix some of those infrastructure issues that drag down all of the efforts. On some level, the infra issues are Most Important because they impact all of the Most Important stuff, right? I can’t seem to find a project for Unblock Most Important Stuff though…let me check Jira. Nope…

Project Unblock Most Important Stuff…funny. Ops is on that, I think, while helping ASB, FQF, Buying Time, and addressing production issues. I need a status report. I mean I guess Buying Time could help, but…You know, it feels like you are getting two things mixed up: the bets you want to play, and how your org is structured. Those are two separate things, in fact. It’s like limiting your job-search to your home town, or not visiting a remote place because you don’t have a four wheeler.

I’m not suggesting you can’t do multiple things at once — the optimal number of things in progress is likely not one — rather that you expand on how your perceive value, priority, and bet playing. And make things explicit.

Doesn’t this defeat the purpose of small autonomous teams? With ownership? Teams should own something right?Backing up, if you include ALL of the people and resources involved in these efforts…is it really a small autonomous team? What if these people are shared? How about marketing? Support? QA? Operations (which we discussed). The Customer. The executive leadership team that hears the status updates. How about all the planning that goes on “upstream” of the team, and all the unplanned interruptions when there are quality issues. Not sure if you know this, but “flow efficiency” (ratio of “touch time” to the idea-to-customer-value time) is often <10%. So most of the time spent has nothing to do with direct work… if that makes sense?

I think I get it. 10% ? Geez. But I mean does it — all this non-work time — really cost us anything provided people are busy? Our teams are working?You can’t view costs by whether people are busy (or not). In many cases having more slack in the system will improve throughput. Less busy = better outcomes. Also: plans go stale, conditions change, and you’re paying for context switching. You’re paying for a highway, but the number of lanes on the highway is only one factor when considering the “cost” of the pipe. Consider car speed, onramp/offramp design, car size, follow distance, driver skill, road conditions/weather, accidents, etc.

I’ve got you! HOV is another list!! These are high priority cars.Again, you’re mixing things up. Cars are cars. People are people. The HOV lane is a design decision — structure — to maximize throughput of the whole highway. One car with 4 people, is 4 cars with one person.

I take the train to work, so….you know I did recently read about what driverless cars will do to highways. Interesting stuff. But wait, why does this all relate to a single list prioritize by value.Because without that list, without that perspective, it is very hard to make sense of what is going on and make economically sound decisions. Unless you can make teams SO independent that they can basically run their own businesses, with all their own resources. In that case…sure make distinct lists and prioritize them individually. Why? Because you can treat them as discreet systems, not small autonomous teams within highly dependent systems.

Are you saying that people shouldn’t have backlogs or individual roadmaps? That sounds very corporate to me.Not at all…filtered views of the prioritized list are totally helpful. And teams should absolutely own the backlog for their mission. But what is their mission?

Isn’t this what a PMO is all about? Wikipedia: “Enterprise PMO: ensures that projects align with the organization strategy and objective; these have the broadest remit of all PMO types, typically reporting direct to the CEO (or similar role), and have authority to make strategic and tactical decisions across all projects.”I guess, but is your PMO thinking in terms of flow, or in terms of project delivery and maximizing utilization….playing project Tetris? Do they think in terms of org design and continuous improvement? I dealt with a PMO once that had absolutely no visibility into the “operational” side of things. They were just focused on cramming new stuff into the pipe and reporting on it.

Oh Tetris! Gotta love that game. They do have this call Red / Green / Orange status chart…But does that really give you a sense of where your throughput capacity is going? Or does it take a project centric view, and a resource allocation view, e.g. placing “chips” (people) on projects?

Ok ok ok. I’m starting to get it. But let me ask you this. I’m hearing three messages: 1) a single prioritized list, and 2) limiting work in progress, and 3) taking a really broad view of everything. But something is grating on me. There are some very real and human blockers to making this all happen.By far the hardest part is the transparency. Perhaps in the past this was just “known” — the less important effort was called equally important, but it wasn’t, or the CEOs pet project was called “strategic” to get it rushed through. But it wasn’t explicit. For that, you need psychological safety and trust.

You are going to hit blockers, and you’ll have a choice…either hide them away, or not. Finally, people see through “fake” autonomy. They sense when the system is highly constrained. So if you want to get to the point where teams can really own their own value streams and be truly independent, you can put that out there as an aspirational goal and keep working towards it.

A single prioritized list of business outcomes/missions, and limit work in progress.