Good Folks!
All deadlines are made up. Yet I see them treated like the ten commandments: set in stone, by god, handed down to lowly developers.
This week I’ll share my mental model for thinking about product delivery scope, time and team scale. It’s not rocket science, it’s really quite obvious imo.
Software delivery is uncertain, pretending otherwise is just fooling yourself.
Let’s do a little thought experiment. Let’s focus on only three variables / dimensions of software delivery and see how they affect each other. Scope of delivery, scale of team and the time for delivery. There’s a natural tension between the 3 variables, in an ideal world they fall into equilibrium by the power of the invisible hand. Once they are in equilibrium, as a rule of thumb, you can’t move any single one of them without moving another. It’s almost like electro-magnetic forces. Allow me to demonstrate:
You can’t increase scope without scaling the team or delaying release.
You can’t downsize the team without decreasing scope or delaying release.
You can’t release earlier without reducing scope or growing the team.
If these 3 dimensions are not in balance your software will be in shambles.
Managers love predictability and hate risk. That’s not a bad thing, really, it’s in the nature of the job. Naturally manager attempt to tame these forces by controlling the variables. The holy grail is fixing all 3 variables in perfect equilibrium. That never really happens though, I think of it as purely theoretical. Or do you remember the last time a business stakeholder or product owner was not trying to add more to a product scope? Me neither.
Let’s take a look at approaches to taming the forces. 2 of which I consider viable. The third one not so much, but I see it in real life on a semi-regular basis. The last one for sake of completeness.
📦 Bundled Releases
= fixed scope + fixed team
Every release has a set of predetermined features, the business dictates what goes into the bundle. The delivery team is stable, i.e. the individuals on the team stay the same as before.
The only free variable is time. In other words, the release date cannot be fixed in advanced. It is moving target. The further it is into the future the more inaccurate is our forecast.
As a corollary we must accept that release date of the whole bundle is uncertain.
🚃 Release Trains
= fixed team + fixed delivery
A team decides to release once in a set period (a day, a week, a month - whatever works). On release day the team releases everything that is ready (as defined by the team).
The only free variable is scope. In other words, the product owner or business can no longer decide “we will release feature X on November 1st”. Instead they only get to decide order & priorities of delivery. After that it’s sitting, waiting and wishing.
As a corollary we must accept that the release date of a specific feature is uncertain.
Both of these approaches are viable and both have the drawback of accepting uncertainty up front. Sometimes that doesn’t sit well with stakeholders, when that happens I often see teams attempting…
🤦♀️ Wishful Planning
= fixed team + fixed scope + fixed delivery
This means no free variables, all dimensions are fixed. I kinda gave it away in the introduction, this only works in perfect balance, which is… never.
It always results in delayed release and/or reduced scope. Business stakeholders, who are counting counting on feature X by a date Y, are enraged. And I get it. What’s the point of making plans when it never works out as planned?! Yet the flaw was in the plan to begin with, trying to fix all 3 dimensions was foolish. This is ultimately why products with roadmaps fail to deliver according to plan.
But wait a minute… couldn’t we just scale the team? Isn’t that a matter of solving our problem with money? And isn’t money the only thing that we have plenty of anyways? Well…
💥 Planning by Spreadsheet
= fixed scope + fixed delivery
Every release has a fixed set of features, our business dictates what goes into the bundle. They also get to pick their favorite release date.
According to the forces of the triangle we can get away with this by scaling the team. Huzzah!
Well, in theory yes, but it’s more subtle. For the next segment we’ll travel back in time to 1987 and have Tom DeMarco and Tim Lister school us.
Louise, your database expert, announces she will depart at the end of the month. Prior to this, you had been feeling pretty good about prospects that your five-person team would be able to deliver a new version. [..] You get Personnel on the phone and give the bad news. “Louise is leaving on the thirty-first,” you report. Then you ask, hopefully, “Can you get me another Louise?”
Unfortunately, Personnel is fresh out of experts [..] “How about a Ralph?” your contact suggests. You have never heard of Ralph, nor has anyone else on the team, but he seems to be the only game in town, so you agree.
In one sense, the project has experienced no disruption at all. You had five people on the thirty-first, and you’ve got five people again on the first. [..] The team will be supplied with precisely five person-months this month, exactly as it would have been if Louise had stayed on. If the project was on-schedule last month, it should still be on-schedule now.
So far, so good. Everything according to the spreadsheet math.
Well, let’s look at how Ralph spends his first day with the company. There was a certain amount of database work remaining that Louise left on her plate when she departed; how much does Ralph chip away of that remaining work on Day One? Of course, the answer is, nothing. He doesn’t do squat. [..] His net production is zero. Whoops, it may even be less than zero. If he uses up any of the other people’s time—and you know he is going to, just to get his basic questions answered—then his net contribution to team production for the day will be negative.
[..] Day Two is a little better. Ralph is now fully involved, reading the notes that Louise left for him. This is work that Louise wouldn’t have had to do herself had she stayed on, since she knew all that stuff cold. (She wouldn’t have had to write the notes either if she hadn’t been about to leave.) Ralph’s production rate is still far lower than Louise’s would have been. He may still have a negative effect. [..]
Yikes. That’s basic arithmetic gone wrong. The excerpt talks about replacing a team member, but I have seen exactly the same dynamic when growing a team. Adding new team members will slow down the team for several months. The more people you add at the same time the more you slow down the team. 😬
Managing by spreadsheet fails because teams, unlike money, don’t scale for free. Growing a team reduces productivity in the short to mid term. Growing a team is an investment in future productivity. Even if you hire the most expensive talent you can find, scaling the team comes at a cost. Similarly scaling down teams has an associated cost, knowledge transfer isn’t free.
Now, most managers know this. The quoted passage is from Peopleware (first edition 1987), so I was really constructing a straw man here. Forgive my pazzazz.
🤗 Embrace uncertainty
In summary this thought experiment shows us that:
Wishful planning (fixed scope, time and team) is bound to fail.
Spreadsheet planning fails because teams don’t scale for free, very quickly we hit the zone of diminishing returns.
Release trains and bundled releases work. Both approaches imply uncertain delivery of individual features/changes.
So we are left with the choice between:
Wishful & spreadsheet planning: look good on paper, but don’t work.
Bundled releases & release trains: imply uncertainty, but work.
What approach are you taking in your organization?
Hyperlinks
How to design remote work?
Over on the Uncertainty Mindset Vaughn Tan elaborates on 2 recurring ideas on his newsletter: open ended roles and negotiated joining:
Employee roles are left explicitly open-ended instead of fully and clearly defined—what I call open-ended roles. [..]
Employees are continually put in situations where they can adjust their roles through low-stakes microtests—what I call negotiated joining. [..]
Am I Growing Complacent Currently?
Apoorva Govind lays out a neat framework to evaluate if it’s time to change your job
Accomplishment: Have I done anything noteworthy these last three months?
Impact: Would I write a line in my resume about the work I have done over these three months? Would I value this specific work experience if I was hiring for my own company?
Growth/Future alignment: Have I acquired valuable insights or skills? Are these skills aligned with my future goals?
Challenge: Have there been days when I was thinking about a work problem in the shower so profoundly that I forgot if I used the soap or not?
Community: Am I excited and happy to go to work every morning and see my teammates. Do I believe in the mission, vision, and leadership of this team or company?
Marianne Bellotti on the Frontmatter Podcast
In the interview Marianne shares how software in government organizations is different (I had no idea) and why she ended up writing Hiring Engineers. There’s a lot of nuggets in there, my favorite one about Conways law (highlight by me):
It's funny to me, because a lot of my writing as of late has focused on people's misunderstanding of Conway's law. People think that Conway's law is some sort of divine mandate that, like, you built it this way, because your org chart looked like this.
But Conway's law is really about incentives, and how people communicate with one another. It's just an understanding that people build things that reflect their current social situation in the place that they're working. And that is fascinating from the ethnological point of view, and just incredibly frustrating from a software point of view.
We write code, not documents
Basecamp’s Dan Kim took a stance against heavyweight diagramming tools. He prefers lightweight sketches on pen & paper, iPad or in code. It’s a polarizing topic, the comments are divided between “preach, brother, preach” and “oh do you even know how to design?!”.
(Dan also gave a great talk on ktor at KotlinConf 19)
That’s it for this week. If you enjoyed this ☝️ leave comment or share it with a friend.