What John Donne Can Teach Us About Software Delivery

No man is an island, Entire of itself; Every man is a piece of the continent, A part of the main.

I keep reading things from agilists and software engineers who are frustrated with the ‘periodic’ calendar set out by SAFe and other frameworks.

“Why do we have to delay delivering working software to the end of the quarter (or sprint)? If the goal is to deliver value faster, why do we chain ourselves to an arbitrary calendar?” (this is a pretty solid paraphrase of a LinkedIn comment I read yesterday)

The exemplars of this kind of delivery are wildly successful brands we all know – Facebook, Amazon, Google. They can deploy multiple times and hour and are constantly pushing functionality to their ever-growing user bases.

So what’s holding you up, developer of HRIS systems?

Let’s step back a moment and ask ourselves what’s true for all three of those companies (slightly less for one…)?

First: no training. We launch Gmail and when the UI has changed, and we’re left to our own to figure it out. Sometimes, for major changes, we’ll get a popover. I count at least three different places Amazon puts ‘add to wishlist’ on product pages, and Amazon can simply outsource the labor of figuring it out to me (note that I’ve ramped back my casual purchases from Amazon and you might consider it too). There are times when I look at Facebook and realize they have changed something and I just don’t bother with it.

Next: no change management (for the most part, and with the exception of Amazon who may conceivably have changes that require process changes in delivery or other physical processes). I may have to coordinate with identity or ad-tech software changes as a part of my delivery – but I don’t have to reorganize employee onboarding, our inventory process, or the month-end financial close.

Next: Minimal user documentation or support. All three of these companies rely on broad ‘patterns’ that their software follows, and trust us to figure out the actual way to interact with those familiar patterns. They have FAQ and online support that is – charitably – minimal. They trust their users to ‘figure it out.’ That doesn’t work for core accounting systems.

Next: No collateral, marketing, or sales. Sales for these firms happen at the brand level, the specific products the novel features represent aren’t (typically) ‘sold’ themselves – so we don’t need to train salespeople, create marketing collateral, or establish marketing campaigns.

I wrote something on LinkedIn that makes my point a bit… #YesEstimates LinkedIn

Look, the mistake here is simple. He sees delivered software as the product. And in a world that used to exist – one where you bought Norton Utilities on a commercial floppy disk with a label printed on a line printer at the local Radio Shack (I did once, yeah I'm old…) – yes, delivered software was the product, and making the delivery of software in and of itself more efficient by eliminating waste was an awesome idea.

But as anyone who has owned a MV Agusta motorcycle can tell you, the ‘product’ isn’t just the motorcycle – in reality.

Once the motorcycle is built, now it needs to be shipped to a dealer, who has to sell it to me – meaning there has to be a logistics chain that operates efficiently, and dealers who will sell it and who are ready to receive it, and have salespeople who know enough about it to sell it to me. There has to be collateral in the form of marketing materials. There has to be collateral in the form of owner’s manuals that accurately reflect how the motorcycle as it was built works. There has to be collateral in the form of service manuals – that accurately reflect how the motorcycle was built. There has to be a supply chain of parts and tools as well as trained mechanics to use them.

Only when all that exists is there really a product.

That complete package – motorcycle – shipping – dealer network – trained salespeople – trained mechanics – collateral – parts – is the true product that a consumer buys.

So if we optimized the hell out of building the motorcycle, and in doing so, crashed all the other aspects of the product – the owner’s manual didn’t reflect how it worked; the service manual didn’t reflect how it was built; the dealer didn’t have tools or parts – what are we doing?

We’re optimizing part of the system at the expense of the whole.

I think my point was valid – but only partly right.

The existence of Amazon, Facebook, and Google suggest that sometimes the system is just the software.

And when it is – we need to ask whether we need the orchestration with other elements or we just need to deploy.

And sometimes what we need to orchestrate is limited (think Office 365, where accurate help files and user training are required).

And sometimes, it’s extensive – where I’m changing MRP or ERP software and need to adapt physical production lines, supply chains, etc.

And so one of the first questions we should ask is whether we’re dealing with an island, an archipelago, or a continent – what is the product and what does the end user require for it to be valuable?

And maybe, just maybe, we need to adapt our approach to what we find out.

So, to all the agilists complaining about cadence-based development (note that SAFe does explicitly say you should decouple deployment from development) – yeah, I’ll agree there are places you have a point and we should move to continuous, sudden delivery of functionality and so deliver value. And I’ll ask you to agree that’s not always true. So let’s look first, and take a position based on what we see.