Collaborate with Purpose
Where does the productivity come from?
I love to cook. I love to cook with friends. I like having a plan. But problems arise when I made a plan to cook something alone in a hurry and someone wants to help me. Often that slows me down and causes frustration.
It’s a great bonding experience if I catch myself doing this and slow down, share the process. But I have to catch myself.
This happened to me countless times while building software. It’s human nature. And it’s happening on your team as well. If you’re still reading at this point — probably more than you’d like.
Strategic vs Tactical Plans
Strategic planning is about unblocking teams, cost-ROI assessments and setting a roadmap. It handles the typical project management aspect of building software.
Strategy answers what the final outcome looks like and why we are pursuing it.
The Tactical often gets neglected — or to put it mildly, gets planned on-the-fly without documentation. This one handles the hour-to-work work by individual contributors.
How it differs from Strategy is that it isn’t a theoretical exercise of “what would a project like this look like? How much would it cost? How long would it take?”. Rather, it makes all unknowns concrete, specifically all estimates and forecasts become translated onto hard earth reality.
A tactical — execution — plan handles the here and now. Putting the next deliverable of the project onto everyone’s calendar.
The difficult part is ascertaining whether 5 people are doing 1 release together or 5 separate ones. Or perhaps something in between?
A tactical plan is about planning your releases. I wrote a whole article on it.
A Solo Plan is difficult to share.
Teams often start at Solo. And never transition out. The outcome may be familiar to you: a team of 5 following 5 solo streams of work.
I like to facilitate this exercise with teams I coach— actually we just did one today which is what inspired me to write about it!
Here’s how it flows:
We start with a list of requirements, a check list or stories
We draw an event model and connect the dots left to right. It will look like a singular linear process at this point.
Then we plan for parallelising with 2 lanes— ie. 2 people
Questions that pop up are:
how do they share the work?
do they collaborate or do two things solo?
do they sync up to move in lockstep or diverge?
do they pair or mob?
if it’s solo, do they require additional work for review - can this result in re-work?
Then we re-plan for parallelising with 3 lanes, etc.
Common Findings
Those of you familiar with Team Topologies will recognise the similarity to service boundary and user needs mapping as well as applying Conway’s Law.
This is where the team usually diverges. You ask everyone to create a plan based on their understanding and voila! Everyone starts optimising different parts of the process. Most notably individuals may optimise based on their understanding of uncertainties and risks around their available resources:
a critical subsystem
uncertainty on task time
uncertainty of outcome
lack of experience with technology
availability of team members
Planning Outcomes
The immediate benefit isn’t the common ground this creates. Instead, focus on where each individual differed. Find the unique insights that the different plans bring first. Act on those insights.
Then piece the plan together into valuable streams. See if you have important platform- or supportive-efforts at hand. This will help you to prepare them and be able to unblock the value-stream team immediately when they’ll need it (ie. for a deployment or mobile testing).
In particular, these are unexpected outcomes that I see teams performing as a consequence of having done this exercise:
Put pair programming focus sessions onto the calendar
Schedule huddles based on outcome not routine
Designate a ticket as the collaboration hub— the task everyone helps with once they are available
Put deployments and dark launches onto the calendar
These tasks are still often unestimated, yet the team knows how and when they’ll perform then. Interesting, isn’t it?
That’s the theory. Are you going to put it into practice?
Try it. What do you disagree with in this approach? What’s valuable?