How To Deliver Software Without Deadlines

Let’s talk about how we deliver software when it’s ready, instead of when it’s due.

A few weeks ago, I dropped what I know about Dateless Delivery on you. It’s a process born out of Agile in which a technical product is only delivered to market when the technology is done. The rest of the organization moves forward with the tech instead of backward from a previously selected, and often times arbitrary, delivery date.

As you might expect, there were diametrically opposed opinions on that post, and I’m thankful for all of them. There were those who cheered what couldn’t be a more obvious way to build a better product, and there were those who called me an Agile zealot and asked me how the view was from Fantasyland.

I’m actually more of a Tomorrowland guy, but whatever.

I won’t rehash the arguments here, that’s the old post. However, more than one person questioned how Dateless Delivery might work.

That’s this post. And it’s not rocket science.

But You’re Playing With Fire

First of all. I’ll say it again as I did twice in the original post. Dateless Delivery is not fully baked yet. While there are teams out there practicing it, they’re usually on the innovation end of the tech, not the core.

The methodology is still mostly custom, meaning it gets done differently from company to company. It’s also still a startup thing, and I don’t expect larger companies to be flipping to Dateless. Yet.

But it is coming. I’m integrating it piece by piece today, trying to turn a custom delivery process into a standard delivery process. This isn’t the invention of fire, I’m not trying to publish the next Spotify methodology here, this is just how I’m transitioning from promising and missing dates to delivering continuous innovation, both across my org and to my customers.

Dateless Delivery Doesn’t Mean No Dates

Before we get into the nuts and bolts, let’s clear up what I believe is a general misconception based on some of the feedback I got: That Dateless Delivery immediately begets a total lack of developer accountability.

Nothing could be further from the truth. In fact, Dateless Delivery mandates more accountability across the org because no one gets to hide behind arbitrary due dates anymore.

We’re still going to talk about dates. Developers are still going to give estimates, those estimates are still going to be aggregated and plans are still going to be made.

What’s more is those estimates are going to be much more honest because the developers don’t have the specter of some already-agreed-upon delivery date that they’re influenced to work backwards from and lie about how they can use some techno-dev-wizardry to squeeze what is obviously a six-week effort into two weeks.

We’re still going to check progress and we’re still going to move fast. Accountability for developers shifts from hitting dates to delivering working software. Which is what we’re paying them for.

Our Product Should Be Driving Revenue

One more caveat. Dateless Delivery is only relevant for a product that is driving revenue for the company. If that’s not the case, then we’re wasting our time. If innovation in an org is figuring out how to get 60 hours of production out of a 40-hour work week, then it’s just a different mission, keep cranking code and Godspeed hitting those deadlines.

We’ll Need Agile

Look, we don’t need to join the Secret Agile Club. We don’t need ninjas or masters or black belts. We just need to steal what makes sense and adopt it into our product strategy. If we’re already doing Agile, a lot of this process will be familiar.

We’ll need continuous delivery, which means we’ll need a production window every two to three weeks (I’m a big proponent of two). If we want to go all the way to continuous integration — updating a code repository several times a day — that’s a good idea too, though not mandatory.

Continuous delivery ensures we’re rolling new versions often enough to lessen the impact of deadlines. Continuous integration ensures that we have stuff to roll.

Once we have continuous delivery, we can adopt as much or as little of the rest of the Agile methodology as we want.

We’ll Need a Product Roadmap and a Product Plan

I’m going to get a little generalized here to get everyone on the same page, so bear with me for a few paragraphs if you’re already doing this.

We can Product Plan however we like — where we work to dates and track progress and mitigate risk. Like I said, even with Dateless Delivery, we’re still doing all that.

The Product Roadmap is everything we’ve prioritized as far out as we we’re willing to go. For us, it’s about 12 to 18 months. I use Trello for this but it doesn’t matter what you use, as long as you have initiatives and landing areas. We’re basically going to storyboard.

Initiatives are features or feature sets written on sticky notes. Landing areas are sections on a whiteboard. For those sections, we want both versions and quarters, and we’ll group them together. So it’ll look like this across the top of the whiteboard:

This Version > Next Version > Future Versions > This Quarter > Next Quarter > Future

If we’re working on version 1.1 in Q1 of 2019, we get:

v1.1 > v1.2 > v1.x > Q1 > Q2 > 2019 > 2020

Then we stick the initiatives where they belong. The ones in v1.1 are what we’re working on today for the next production roll, v1.2 is the production roll after that, v1.x is undefined but prioritized.

Then Q1 contains features that are not prioritized but important, and as importance wanes, the initiatives slide further to the right.

Here’s a sample of the roadmap, I didn’t show Q2 2019 and year 2020 to save space

None of these have due dates, but we’re rolling every two weeks. When we roll v1.1, we remove that landing area and add a new landing area v1.3 between v1.2 and v1.x. We take the initiatives that didn’t make 1.1 and move those into 1.2. If 1.2 overflows, we push stuff out of 1.2 into an empty 1.3. Then we fill the rest of 1.3 with stuff from 1.x. Then we keep moving stuff to the left as it makes sense.

Now we have a constantly evolving product and also a heads up on the likelihood of when future versions are going to come online. There are also no hard and fast rules. If we want to slot versions 1.1 through 1.9 or whatever, no worries.

We’ll Need Control

In order to do Dateless Delivery, we’ll need control. And that control only comes when we get buy-in at the executive level. Furthermore, control should be on the product team. And finally, the product team should be product engineering, not product management or product marketing.

The dawn of the Chief Product Officer coming up through the ranks of engineering is here. But that’s another post. Suffice to say, we need to have a tech-minded person who understands the full lifecycle of product development at the helm of this delivery system.

Here’s why.

The main argument against Dateless Delivery is that there is always some buck-stopping entity with a firmly planted release date that can’t be moved. It could be our boss, our VP of Sales, our CEO, our investors, our customers, anyone with more weight and power than the person or persons responsible for delivering the product.

My pushback to that argument is this: It’s the job of the persons with power to make the continual argument up the chain that the product must be the top priority, not the date. As ammunition, I’ll reuse my mantra from the original post: Selling 10,000 working units can often lead to selling 1,000,000 units. Selling 100,000 broken units won’t. Ever.

So we need that product champion. If we don’t have it, then everyone needs to influence their boss with that mantra. And as for the customers, who are always the top of the chain, I’ve never met a customer who would take a broken product on time over a working product late. So we need to let them know that we’re presenting that choice early enough so that they still have time to create flexibility in their own schedules.

I know. This does not happen overnight. But if we don’t get started it’ll never happen.

Constant Prioritization and Constant Communication

Priority and communication are a collective effort, working with the executive level, sales, marketing, and support to keep everyone in the loop about which features are targeted for which release and which are moving. The product roadmap is shared with everyone in the organization, so those teams can adjust their plans accordingly and communicate out accordingly.

Then, once we have constant delivery and constant communication, we can talk about constant prioritization. Our product should always be evolving and we should always be learning from the data coming in.

Building features 18 months out is product suicide, because I guarantee you that the data used to prioritize that feature is irrelevant 18 months later. But with dateless we can shift gears much more quickly. If the data is telling us our customers will pay more and sooner for Feature X over Feature Y, we can slide Feature Y into an earlier release and slide Feature X out. Sometimes customers won’t even miss Feature X, especially those that want Feature Y.

We’re Still Assuming Risk, Just Safer Risk

Dateless Delivery isn’t a panacea. We shouldn’t be adopting it because it’s new or it’s cool or it’s the latest buzzword we’ll need to know to keep our job.

We’re living in an increasingly time-agnostic world. Newspapers are no longer delivered in the morning, they’re online (when they still exist). There is no more “drive-time” radio, there are podcasts. There is no more appointment television, there is binging. Video games are played in beta for months before their release date.

Yes, there are tons of time-sensitive deadlines out there, but the cycles of adoption are changing too. Fewer people rush out for the latest iPhone, movie releases are heading to Netflix and out of the 8:00pm theater slot. Sure, there’s the Superbowl and other timely events like it, but even then, businesses are advertising brands and feelings in those circumstances, not specs and features — ie. they’re already hedging against missing dates.

When we start to understand that shift in how we’re living, working, and consuming, we start to consider the bigger picture, and we start to see the fault in that the only thing we’re going to stick a deadline on is the thing that’s the most important to get right.

Hey! If you found this article insightful, please consider signing up for my newsletter at joeprocopio.com. I write real-time, real-world startup advice posts twice a week, and I send out a short email once a week that's really more of a 2-way street.