Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
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.
A Single Prioritized List (a Story) was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.