I remember how eager I was earlier this year to hear what Phil, the prophetic groundhog, predicts about spring. There’s a special reason for that: as the name of my post suggests, it had to be published not before we felt something close to what it actually is about — joy spring! Not even that much surprising, but Phil’s prediction turned out an epic fail, as spring got delayed beyond any reasonable standards. Finally, about 2 weeks ago, spring remembered about us, the freezing folks. Even Phil, the Groundhog, screwed up with his estimate, and while the spring is already far in, it’s high time to come up with a very fitting narrative of what missed deadlines, and deadlines in general, are about.
Apart from spring itself, there’s actually one more reason for joy. We’ve finally come up with TargetProcess 2.24, the spring 2013 release. The keyword is “finally”. We were supposed to be done with it much earlier. But it appears the release wouldn’t want to venture into the outer world in any other weather than the spring one (thank you, Phil).
Enter Deadline (escorted by Estimate)
Jokes aside, I wouldn’t be mistaken if I said that many meetings in software development are supposed to dissect the reasons for missed deadlines, or delivering later than expected. I’ve been interested in studying the metaphysics of deadlines for quite a while (see my earlier post, it dates back to 2009). Now, if deadlines are in the spotlight of most meetings, which typical questions are supposed to be answered? And, what’s more important: even with answers to these questions in place, are we getting down to the roots of the real business “pain”?
Some of those questions would be: Why are we late? Why were our estimates bad? Maybe someone under-performed? 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 there’s the rhetoric of guilt and who’s-to-blame. 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 bad estimates” part, you can throw the time that you’re spending at 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 (actually though, there’s quite some talk about the delusion of estimates at this time).
Stunning. It appears one cannot rely on estimates, and can’t set a 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 at the end?
I think that this whole concept of deadlines is built on fear and insecurity. Something very old-fashioned and 19th centiry-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 fit for manual work. They’ve 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 they have been sitting seemed steady like a rock, and it never or rarely occurred to people that deadlines are actually a mess. Or, a cautious tinge of a thought like “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 for me that the harder the push, the less far off is the actual release date. That’s usually the case with what I call “subjective” deadlines.
Subjective and Objective Deadlines
Deadlines as a biological species in corporate environment can be broken into 2 subspecies: subjective and objective. The universal law that I’ve derived has it that about 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 the company will sink into the financial abyss, or the competitors will come up with the same thing that very day. 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 huge product dev companies, when marketing stakeholders plan rigid timeframes for marketing campaigns and activities, and devs are not involved in that. That’s the case of disconnect, and every party has to balance their needs and reality.
The objective deadline is this:
- Something huge. The Russians are now busy building the infrastructure facilities for the upcoming 2014 Winter Olympics in Sochi. 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 the lives and well-being of people. Like, to rescue people from the flood that can wipe away their homes or from other natural disasters, or any other events like that (well, we’re very much into the movie crap of being immersed into all kinds of bad things, like saving the planet just on time before the aliens launch their rocket etc. so I’d let your imagination conjure up any other instances like this).
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. 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.
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, good 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 wouldn’t understand how I’m messing 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 each other, and we can’t go any different than by finding a common language to share and 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. This observation relates mostly to emotional deadlines, and is about the silent reciprocal understanding of why we get stuck on our way to the golden release date.
It’s nothing else than the issue of relationships and unity in an organization, to have marketing adjust to the reality of fuzzy estimates and deadlines. Looking at many companies, and at their release dates, I’ve noticed an interesting trend. Major releases usually appear 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 ”to do’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). It’s 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 help with such questions and managers, though, should you encounter them in your life, is the intelligent “get done” forecasting. As in this report.
You can take these percentage probability forecasts, and show them to whoever needs an estimate of completion. If you’re curious, that’s one of the reports that we did in the recent 2.24 release. It can even work for service companies, if they have done the bulk of the enlightenment work about the fallacy of deadlines with their customers.
It might be hard to comprehend but unless we all become the beacons of the new 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”, they have nothing to do with technical failures. Rather, people are not sure how should they manage communications and resolve organizational issues. Software development is more about humans as ever, since it’s getting still harder to live with no ecosystem of understanding and cooperation to replace the split reality of deadlines.