Deadline Dread

There are three types of deadlines: rational deadlines, abstract deadlines and real deadlines.

Too often lately “agile” has become either an excuse or a “solution” for deadline phobia. Because things cannot be endlessly fiddled with, generally any stakeholder involved in the development process will, at some point, require something done in a certain timeframe.

One of the problems of deadlines is that they are wrongfully understood as the end. Here comes Iterative Development to the rescue: deadlines are just different stages that the product goes trough.

Another problem with deadlines is that they tend to be perceived erroneously as huge walls that are approached at full speed — and just because of that they cause stress and poor execution.

When a deadline is regarded as a roadblock that you’ll smash into, unless you can somehow do a stunt on it, the solutions to come up with are poor: bloated teams, cut features, sliced specs, dirty hacks, bug ridden results.

A deadline is just this: the end of the timeframe that starts now.

When you look at it this way it no longer frightens you. Its just a constraint imposed on time for some reason from which it results an interval, a timeframe, made of a given number of days. Your problem is what you can do best with this amount of time that you have, a problem well put by Gandalf about life in general “all we have to decide is what to do with the time that is given us”.

To escape deadlines we have a quick and elegant solution that is called MVP — minimum viable product. The idea is that you don’t care about the date of the deadline, but only about what can you currently can deliver in that amount of days. MVP teaches that you should only strive to implement the core features that allow deployment, and no more.

The art here is to be able to self asses honestly and clearly. There are situations in which self assessment is hard such as when the team is just assembled and you really have no idea how fast you can do anything. There are situations in which clarity is hard such as when there is no study on the market or customer and you’re working on assumptions. Assumptions are usually false unless they’re scientific theories which are usually false too.

MVP however works very well, even in bad situations, because the theory is sound. As Jon Radoff put it, an MVP is not a minimal product, its a product that is small enough to be affordable and viable enough to be deployed. Affordable can mean a lot of things and it includes: cost effective, timeframe realistic, know how realistic and so on. Deployable can mean many things from saleable to functioning, it depends on what you set sail for.

MVP is not dirty coding hacks to quickly deploy crappy products that nobody will use. MVP is not cutting out features to create undifferentiated offers that nobody will notice. Lets look at the acronym again: MVP — minimum viable product. Minimum means the least required padding that is absolutely necessary around the core of the product. Viable means it has to work for the customer, to solve a problem, to be a scratch for some market’s itch (markets include segments of customers you already have). Product means it has to be self contained, explainable on, the eternal cliche, “back of a business card” space.

The key to implement MVP successfully is to start backwards with it. First of all think about the Product. First of all is it a product? If its not a product you have a major problem because you will not be able to make a project out of it. This tends to be the case with ideas, inventions, generic solutions, avant-garde creativity and weekend projects. Also if the business is up and running consider whether the problem at hand is not customer support, a marketing and communication issue, a bug, a nice to have and so forth. Then do the famous Feynman exercise and try to explain what you’re trying to accomplish to a total noob and see if they get it. As the master of this practice put it, if you cannot explain something to the layman you have not understood it yourself.

So the Product part in MVP means clarity, firm affirmations about what you want to accomplish, why and how is it adding any good to the world (and thereby producing some profit of course, yes even charity or NGO projects produce the so called social profit).

Then continue on this backwards path to the Viable part. Viable means identifying the core of your Product. It is not to be confused with the description of the product! The core is the definition of what is essential to make the Product work. For example, the core of a consumer search engine is result relevance. Its not indexing of data as you’d expect, that is a function that supports the core. The core of a search engine is to help the user find. If it were an exhausting database then, and only then, indexing would be the core.

This then brings us to Minimum. After you have clearly defined what you want to accomplish and found the core of it, its time to identify what is the least necessary support for the core to exist and function. In the not Google example above, a large chunk of web indexed is necessary so that you have something to search into, but minimum means you don’t need the entire Internet, even that not evil company merely searched trough Stanford’s web in the beginning. So one website was the Minimum required to make the core — the relevance algorithm — work.

But having the MVP method in mind and explained lets get back to deadlines. As i said above, a deadline is merely the other end of a timeframe which starts now. There are three types of deadlines: rational deadlines, abstract deadlines and real deadlines.

Rational deadlines are the best kind.

They usually are a conclusion to some sort of plan. Because of that, a long list of assumptions has been made before the rational conclusion has been reached that some deadline is set. Most of these however tend to be too optimistic because people have the bad habit of planning for way too large spans of time. However if the time span is reasonable and the planner capable, its the best type of deadline you can get. Its also the most flexible type because you can adapt constantly to change.

Abstract deadlines come from a need.

Cash flow is most often the need to be solved (there are numerous companies effectively ran by the sales plan), but other types exist as well such as personal reasons of the people doing the planning (fame, promotions, bonuses, bragging rights), dependencies inside programs or large projects (i can’t do this if i don’t finish that — which by the way is an architecture problem not a project management one) and other similar things. These are the deadlines which are probably the most missed in the world and they are the main cause of bad project management. I don’t have a statistics for that but its not hard to imagine the pressure and stress coming from a vague restriction that cannot be properly understood by everyone involved and then the poor results and low productivity rising like a malevolent Saturn in an astrogram.

Real deadlines come from the real world

… and 99% of the time they exist because we use a calendar: events, celebrations, ending cycles (financial, executive terms etc.) and so forth. These are the deadlines that caused most failed products in history (e.g. Windows Vista). Why? Because you cannot fiddle with the placement of Christmas in the calendar or the quarter reporting of a public company. You absolutely have to deploy by that date, and because of that crappy products spawn endlessly.

In managing software production projects you will have a mix of these types of deadlines and this is the exact reason why you should keep the tabs on wether or not you are following best practices or if you have strayed.

Rational deadlines are solved by Agile Development Methodologies because they will reveal your speed and they shorten planning spans resulting in the magical ability to foresee the future (because it gets to be a week away) and take far more rational decisions.

Abstract deadlines are solved by doing Iterative Deployment because they are like a medicine for a health problem, gradually solving it by small amounts of substance. If you’d take the whole amount of antibiotics to solve a bad bacterial flu in one day, you’d have a bigger problem than the flu in the next ten minutes.

Real deadlines are solved by the MVP you put in place. If your MVP is correct, its not a watered down version, a dumbed down deployment, a trick to fool customers in and so on, then chances are you will have it when the event happens. In the case of this type of deadline its important to realize that you actually have a great advantage in that you identified something real to tie your product to as its a lot better to sell or launch when everybody is waiting eagerly than in the enormous noise of a random day. So treat it like an opportunity constraint and mind your MVP.

So, with all that being said, no more deadline dread!