Springs, Falls, and Estimated Deadlines
I’m usually very eager to hear what Phil, the prophetic groundhog, predicts about spring, and there’s a certain excitement in the air, as seasons change from winter to spring, and from summer to fall. The joys of “falling into fall” remain on a quieter side, however, because no one is particularly enthusiastic about parting with the summer and heading into the fall’s rains and coldness. However… there’s a certain beauty in any season!
Point is, people rarely push for predictions and estimates as to when any given fall will replace any given summer. However, they do push with the spring-winter leg of the seasons change, and for understandable reasons: when you’re freezing, all you want is just more sunshine, and more warmth! Given the amount of pressure and expectations, no wonder that the predictions by Phil, the Groundhog, often turn out to be an epic fail, and spring gets delayed beyond any reasonable standards. If even Phil, the Prophetic Groundhog, screws up with his estimates, how can you expect fair predictions and estimates from humans, regardless if they’re helped by all kinds of data, or not? *ironic*
Actually, this watercooler-style chatter about seasons is supposed to provide a launchpad for some in-depth reflection about missed deadlines and deadlines in general, so… buckle up because I’m about to give you some wholesome food for thought! :)
Enter Deadline (escorted by Estimate)
Jokes aside, I wouldn’t be mistaken if I were to say that many meetings in software development org’s are supposed to dissect the reasons for missed deadlines, or for delivering later than expected. I’ve been interested in studying the metaphysics of deadlines for quite a while (actually, my very first blog post was about deadlines, too). Now, if deadlines are in the spotlight of most meetings, which typical questions are supposed to be answered? And, more importantly, even if the answers to these questions are available, do they help get down to the roots of the real business “pain”?
Some of those questions would be: Why are we late? Why our estimates were inaccurate? Maybe, someone underperformed? The sacred holy deadline has everyone dancing before its altar like puppets on the strings. It isn’t unfamiliar for people to have this nagging feeling as they come to a meeting and expect that someone’s head is about to be cut now. Especially if a rhetoric of guilt and who’s-to-blame is used. It’s natural (I’d say that it’s unnatural) to assume that a missed deadline means we should chase and track down the bad performers. As this subdued air of someone’s guilt or bad performance takes lead, and people focus on the “why the estimate is bad” part, you can throw the time that you’re spending on this meeting to a waste bin.
Usually deadlines are tied to estimates like addicts to abusive substances. There’s no deadline without an estimate. If you’ve spent ~3–5+ years as a project manager or a product owner or a Scrum master, or as anyone else who relies on the estimates of completion, you’d know that softdev work can not be measured and predicted due to its very its own nature, at times even with no acceptable leeway margin. Ron Jeffries has summarized this rarely outspoken truth very well in this post (and there has been quite some talk about the delusional nature of estimates in software development over the recent years).
Stunning. It appears one cannot rely on estimates, and, therefore, there’s no way one can set a trustworthy deadline, or predict a release date. With stakeholders, or marketing people, or clients wanting you to commit to a time, this seems like an extreme nonplus. How do we go about it, and how do we persuade those stakeholders that life without deadlines is not only stress-free, but it actually means a better quality software in the end?
I think that this whole concept of deadlines is built on fear and insecurity. Something very old-fashioned and 19th century-ish. Okay, now if we have a deadline as a whip, our horses will exhaust themselves to get the carriage out of the mud and will deliver on time. That’s a bit of an exaggerated comparison, but what else can come to mind if people are pushed to do something faster and to stretch their limits AND for no valid reason. Well, the reason appears to be very valid. His Majesty Deadline. If we miss it, then the Earth will sure stop turning, the sky will fall down on the sun, and the seas will dry out.
Deadlines have been inherited from the distorted ways of the 19–20th century which were fit for manual work. These legacy practices have been dragging along like heavy but unnoticed shackles on our feet for 20–30–40 years (depends on where we start the countdown for the onset of knowledge work industries). Somehow the pedestal on which the Deadlines have been sitting seemed steady like a rock, and it never occurred to people that deadlines are actually a mess. A cautious tinge of a thought such as “is that all a huge scam?” would have meant going so much against the mainstream of established outdated ways, that rarely did anyone dare speak up.
I’ve always been uncomfortable about the concept of chasing and being in a hurry to release. Ironically, if a release has been pushed against a deadline, and the horses have been whipped, funny thing, but it did become a sure sign to me that the harder the push, the less far off the actual release time is. That’s usually the case with what I call “subjective” deadlines.
Subjective and Objective Deadlines
Deadlines as a species in corporate environment can be broken into 2 subspecies: subjective and objective. The universal law that I’ve derived has it that ~90% of subjective deadlines can be turned into having no deadline at all! As for the objective deadlines, it’s harder to tame them, but there’s still a way.
A deadline is subjective:
- For a small product dev company: there’s an emotional desire to come up with a new release faster for the sake of just faster. Usually, this is something that a stakeholder wants to do because he/she believes that this release needs to be out ASAP, or else the company will sink into the financial abyss, or the competitors will be the first to release this thing. Or — the real classics — the production guys have estimated that the release can be expected at a certain time, and marketing has made it public as the official release date.
- For a softdev service company: usually service companies deal with the 2nd tier of subjectivity in deadlines. It all very much depends on their customers, and since how long have the customers been working with this company, and the bottom line: how much trust do the service company and the customers have in each other. This same situation also occurs in large product dev companies, when marketing stakeholders plan rigid timeframes for marketing campaigns and activities, and dev’s are not involved into that. That’s the case of a disconnect, obviously, and every party has to find a way to balance their needs accordingly.
The objective deadline is this:
- Something huge. Like, if an Olympics is coming up, a host nation is supposed to construct the infrastructure facilities by a certain time. This IS a deadline. It can not be missed, and the Olympics construction projects can well be treated with the same intensity as the operations of the military.
- The next possible instance is a grave event threatening human lives and well-being. People are supposed to be urgently rescued from a flood that can wipe away their homes, or from other natural disasters.
This is it. Just think about it. The majority of deadlines are subjective man-made disasters. Someone has said that human side comes a long way before software is made, and deadlines are not about the technical side but about people’s nature mostly. Actually, what I’m doing right now is breaking into the sacred sanctuary of “this-is-technical-you-know-nothing-about it” stuff with my liberal arts/humanities white gloves on, and graciously pulling all kinds of nasty misjudgments about software project management out of their holes.
No Deadlines?
My conclusion is striking. We tend to think that problems with deadlines have to deal with the technical issues and technical competence, and meekly mumble about who’s done/not done what as we look for justifications. But that’s not true. Once you’re in the environment of professionals, well-rooted into the team, with good contextual AND open personal relations, then the problems float into the realm of how people make their point to each other and how they adjust to each other’s idiosyncrasies. For example, it’s beyond my understanding how endlessly can designers mull over a tiny UI element. To me it makes no difference. In their turn, designers or developers might have a hard time understanding why a UI writer messes around an error message in the product UI. Or a piece of micro-copy. There’s no reason to be mad about it. In a way, we’re aliens to one another, and we can’t go any different than by finding a common language to share and to understand our idiosyncrasies. Let alone the idiosyncrasies about design and copy, the most unpredictable part is software. You never know when you can stumble upon an unexpected impediment, ask any developer. Sure thing, it would be stupid to rush the developers knowing that they are competent, and they are working on the problem. As a side note, this observation relates mostly to emotional deadlines and implies a silent reciprocal understanding as of why we get stuck on our way to the golden Release Day.
Deadlines, to recap, mostly deal with nothing else than the issues of communication and unity at an organization, as non-dev stakeholders work together with the production folks to balance each others’ needs. Looking at many companies and at their release dates, I’ve noted an interesting trend. Major releases usually are out either in spring, or by early fall. That’s quite logical: winter is winter, with its Christmas time, the late fall is Thanksgiving, summer is the time when people go on vacation. This means, one can assume that late February-mid-March are expected release dates, but silently allow the possibility that it would really be mid-April-beginning of May. Or, for the fall releases, make it mid-August but really count on mid-September-October.
As much as I’m an opponent of “how to’s”, it appears I can finally commit to the one imperative how-to:
Never push people with “when” unless it’s a matter of life and death.
Only hearing this question might make them feel nervous (read, distracted from work and performing worse). This largely happens because of the ever-dragging legacy of the old-school insecurities, the clash of the need to give estimates, and not being sure exactly of what is to be estimated, and the subsequent threat of being labelled as someone non-delivering to their expectations.
One of the things that can actually help in talking about deadlines and estimates with non-dev-stakeholders would be the intelligent “get done” forecasting, as e.g. in lead and cycle time reports:
You can take these percentage probability forecasts and show them to whoever wants to see a visual estimate of completion.
It might be hard to comprehend but unless we all become the beacons of the no-deadline culture, we’d remain stuck in the outdated manual labor thinking amidst the technological progress of the 21st century. Take a look at this link. It’s a well-known Q/A resource for project managers. All of the questions tagged “deadline” have nothing to do with technical failures. Rather, people are not sure how they are supposed to approach communications and resolve organizational issues.
Software development is more about humans as ever, and it gets harder and harder to live by with no ecosystem of understanding and cooperation in place. And, call it idealistic, but my belief is that this ecosystem will eventually replace the dysfunctionality of deadline-based thinking.
Related:
Cloudy with a Chance of an Estimate
The (Agile) Estimates Overkill
Further reading:
This article has been re-written from an earlier story.
