This is a response to Mark Suster’s essay on scope and deadlines:
How to Deliver more Software Projects on Time.

Mark argues that deadlines (used responsibly) are a great way to focus your team to deliver on time or at least way sooner than without deadlines.

I don’t think using deadlines to manage feature creep is a good idea and in this opinion piece I’d like to share some alternatives.

But first let’s look into why Mark is on to something here.

Design with no constraints becomes a research project.
— Mark Suster

I bet everyone who has worked on a software project knows what Mark is talking about. If you don’t put any constraints on a task it tends to take up infinite time.

You don’t want this to happen.
Engineering resources are super costly.
(Let’s not even get into the opportunity cost of these situations)

Deadlines are a simple Hack against Feature Creep.

So why do deadlines help? They force you to commit to something that is shippable until the deadline. Deadlines serve as a trigger to prioritize and to think about trade-offs.

Prioritization and trade-offs are critical because there are countless ways to build something. Prioritization and trade-offs enable editing decisions.

Feature creep, creeping featurism or featuritis is the ongoing expansion or addition of new features in a product, such as in computer software. Extra features go beyond the basic function of the product and so can result in over-complication rather than simple design.
— Feature Creep, Wikipedia

Deadlines help to manage scope. Deadlines are simple.

All things being equal I’d clearly prefer deadlines over never committing to anything and letting things slide.

Doesn’t sound too bad.
Hell, deadlines might actually be a great idea to manage software projects.

If I’d be naive I’d even build a project management methodology around arbitrary deadlines.

Oh wait, we already have one — It’s called Scrum.

Scrum is an institutionalized Death March.

Scrum at its core is based on recurring arbitrary deadlines.
Separated by planning days where the team estimates what it can get done until the next deadline/release.

Unfortunately these deadlines aren’t side-effect free.

Sprint planning days used to be an okay-ish investment.
If you look at the origins of Scrum in the 90ies it meant having a planning session every 2-6 months (yes, those where the days …).

But today many teams practice one week or two week sprints.
This means way more planning days than in the past.

Some teams have to spend up to 20% of their time on estimation of work packages for the next arbitrary deadline instead of what they really care about: building great software.

On top of that these estimation sessions tend to set you up to something you can’t possible deliver on. It’s basically impossible to get the estimations right in a real world scenario.

This is highly demotivating. Basically a how-to on “death marches”. ☹

In project management, a death march is a project where the members feel it is destined to fail, or requires a stretch of unsustainable overwork. The general feel of the project reflects that of an actual death march because the members of the project are forced to continue the project by their superiors against their better judgment.

I believe doing away with arbitrary deadlines and moving from Scrum to continuous delivery is the way to go.

Fortunately we have better alternatives to manage scope.
I hope I’ve piqued your curiosity. Here we go … ☺

Manage Scope by Editing

In software projects editing is one of the most valuable activities.

Editing is incredibly hard and it takes some time to get good at it.
Yet every time you manage to make the right calls a lot of value is created.

Here is Jack Dorsey of Square and how he thinks about editing …

Two things that can help you with editing features are anti-roadmaps and filter lists. Less is more.

Manage Scope with Job Stories

Another opportunity to manage scope are great definitions of what should be built and why. Again this isn’t as easy as using deadlines but way more effective and sustainable.

As the purpose behind a certain change becomes clearer this also increases motivation and creativity as a side-effect.

Instead of thinking in features or personas as sources for what you decide to build focus on jobs and use-cases instead.

Designing successful products means observing how real people solve problems now, exploring the context of the situation they are in, and then understanding causality, anxieties and, motivations.
— Alan Klement

Focussing on job stories helps you to explore and define product changes based on first-principles instead of on weak assumptions that are easy to get wrong.

The Intercom blog has a great post on job stories.

So in a nutshell I agree, deadlines can help with managing tasks that would take up infinite scope & time otherwise.

But being specific and investing time in defining what exactly makes a certain change valuable are better alternatives.

If you need deadlines to limit scope you are fighting against symptoms.
Editing and job stories are effective cures for the root cause. ☺