Why do we need predictable deliveries?
Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.
Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.
I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.
Granted, every industry is different and some rely on trust and predictability more than others. Building an organization that is good at that is very difficult - and that cost has to come from somewhere doesn't it? In my experience it's at the cost of time spent building the product. A tradeoff between reliability and quality, if you will.
Of the software I use (slack, cloud infra, vim, Jira) exactly none of them tell me precisely when a feature will be delivered. They work hard on it and release it when it's ready.
A deadline like "in a few weeks" is acceptable. A deadline like "in 17 days" is asking to be missed.
Internally, though, Slack et al have targets and expect to deliver feature X by the end of sprint Y. They just don't tell you in case it slides by a sprint, and to avoid laying out a product roadmap for fast-moving competitors.
If you give 2 software developers the same software spec they will give you 2 completely different pieces of software.
The code is the blueprints.
If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an amount of time that is unknown at the beginning.
However that's not really what I'm talking about. Assuming some minimum level of quality, 2 houses built from the same blueprints with the same materials and finishes, in similar locations, and by similarly skilled craftsman will be pretty much indistinguishable from each other to the end user.
That's not the case with software.
I like kanban, a stack of tasks with predefined dependencies determining if a card can be picked up, and sorted in priority order once they can be picked up. When something critical goes wrong, the entire team stops and works the problem individually, competitively , until the problem is solved, and the team then resumes their prior work. CI/CD delivers to production, features are enabled when they are ready and the customer is ready. Feedback goes immediately back into the stack and delivery leads constantly manage the feature flags, the stack priority, and inter team communication. The devs just dev and stop the line. The team tech lead, product lead, delivery lead, architect, and program/product lead do all the negotiations and priority setting. There are no estimates. You deliver constantly. You need strong leads and architects to run this way, and you should probably coach your client to expect slow change at first, and rapid change after the first release.
Done this at several clients, for several different domains, with lots of interdependent teams as a consultant, and it is highly productive. The one time it failed, we didn't get buy-in on feature flags in production and the client insisted on batched release branches and long-term maintenance branches for those cut releases.
The other, minor failure, is that it is very prone to momentum. That's when teams get overconfident that they can fix problems in-band with tasks (because they've been successful for so long), and are resistant to stopping the line. This can be spotted by a person not delivering a pr for more than two weeks, or not transitioning a card to done for more than two weeks. Tech lead calls a meeting, determines the issue, decides on stop the line or not.
It works. It's iterative. It keeps the number of communications channels and decision stakeholders low. It cross-polinates through linked dependencies. It ensures product cohesion thru feature flags. It evades critical missteps and bugs via stop the line. And it works well with our modern SSO dev/platform ops and integrated toolsets (Atlassian/clickup + ci pipeline of choice where docs, features, delivery can all talk to each other and reports can be generated for leads that pull from the integrated tools). It doesn't fix Conway's law, but I am not sure that actually needs fixing in truly large development houses.
Software is arbitrary logic which many stakeholders expect to be magic. It's not the same as any kind of construction project.
Thats like asking 'how does naming my local variable X instead of Y have any dependency on code in other functions? and assuming that summarizes the complexity of writing code.
I take it you have never built a large custom house from scratch.
Yes, I have been privy to the pain of custom home builds and remodels. The difference is, when someone says "oh damn the plumbing isn't working as well as we would like", when the contractor says that's not feasible to fix without gutting the house back to studs at the cost of hundreds of thousands, people understand that intuitively. They don't say "can't you just drill some holes and run some new pipes diagonally through the living space".
Software is malleable, opaque, and ever-changing. Construction and maintenance costs of physical infrastructure can be explained in a way that a reasonable lay person can understand. That is not true of software at scale.
This is basically exactly the point. It's incredibly difficult to predict building 'large software'. So, lets try a few things to help make it a little bit more predictable by trying to predict smaller increments.
> Why do we need predictable deliveries?
Say I'm building a piece of software - maybe an app the audience would use - for the Superbowl. It's very handy to be able to estimate our progress to see if we'll actually land that date. The Superbowl isn't going to move because of our app, and our app isn't very useful the month after the Superbowl.
I think this sort of thing - where what you're building has external hard-to-move dependencies - comes up more often than you think. Those election visualisations on NYT didn't build themselves. There's often a bunch of less-hard-but-still-inconvenient dependencies as well - you're building software for hardware, or there's advertising campaigns in planning/motion.
Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!
Now you understand sprints
And software that can't be estimated is still useful, even if you can't plan releases around it yet. "Apple has been unable to accurately estimate any release window for the Apple Car or Apple VR. Therefore no one should invest in it." would be a pretty silly statement, right?
That's exactly how it works though. Imagine Apple's stock price if they announce the Apple Car, without a release window. Now imagine that they come back the next day and say "oh by the way, we're aiming to release it in 2086." What happens to the price? It goes down. There was an implicit estimate used to judge the value of Apple.
Likewise, all software has an implicit estimate. There has to be! Without one, it's worthless.
Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
Yep, at the end of the day, the whole world can't run if everyone is a professor emeritus just freely exploring random possibilities, even if it would be hundred times more efficient to just "get out of the way".
You just have to sign a standard contract for building a project in 24 months, and wait 23 and a half to be in that situation.
Managers need a tool to avoid reaching that situation and renegotiating the terms in advance.
Because your organisation answers to shareholders on a quarterly basis.