"My organization is very date-driven. Every request comes with a deadline. They want firm commitment to a date for everything we do."
I have heard that observation from many teams and people in delivery roles, usually followed by "how do I convince them otherwise?".
Some will also add that they tried the "dates are not agile"-argument, that "we need to be driven by value, not dates", but that it failed to produce any change. "How do I explain this better?", "how do I make this point more convincingly?".
I've never seen the "dates are not agile" argument go well; it just fails to acknowledge that we do things for business reasons. So, to "make this stop" we should be looking to understand those business reasons.
What kind of date is that date?
Some times, dates are externally imposed by other entity with some authority over you:
"The new provincial regulation will enter into effect on Oct 31st. After that, if not compliant, we will loose the license to operate in the province of Quebec."
In cases like the example above, there might be a good reason for the date, or not, but it's largely irrelevant because the external entity (usually a regulatory body) simply has the authority to impose these kind of deadlines (and to enforce the negative ramifications of missing it).
In other cases, you're given a date (or asked for one) because there's the need to coordinate with other initiatives happening in other parts of the organization:
"The system needs to go live on November 1st. That's when the pipes and machinery will be installed, and fluid injection and pressurization tests are expected to begin."
In the example above, we were building some software that was part of a large engineering project. The company was building physical infrastructure that was expected to be completed by November 1st, when some other very costly integration testing and certification was scheduled to begin, and the software was needed for that. We were just one piece in a larger orchestration effort.
In both examples, the date is completely outside the control of the delivery team (or even the organization), and the main motivation for the it is the high impact and negative ramifications of a late delivery.
In some other scenarios, the date reflects the expected decay of value of the work we're delivering:
"We need the Christmas Promotion to hit the website no later than November 25th, so that it can run for at least one full month. But having it live earlier would be great too!"
In this story, the Business wanted the promotion to go live as soon as possible, but they were warning us that after November 25th, and based on their understanding of the behaviour of the target market, its residual value would rapidly diminish.
What all these stories have in common is that there is a substantial "cost of delay" associated with the deadline, which then translates to a legitimate business reason for it. In circumstances like this, it should be no wonder that calls for "being less date driven" go unanswered.
All that said, some times your questions about the nature of the date will reveal that it's just an arbitrary "line in the sand". If you ask questions like "what happens if we're 1 week early? 1 week late?" the answers will reveal that the date is not very significant, other than because of "we need to hit it". In cases like this, my guess is that you're dealing with a problem of trust.
What's your delivery track record?
"There always has to be a date", a former boss from my past used to say. His experience had taught him that without explicit dates commitments, projects would simply drag on and on, with no end in sight until the very last minute, often guided by criteria in conflict with many other business concerns.
Truth is that our industry in general doesn't have a very good track record on timely delivery. Adversarial relationships between delivery teams and their customers are common; add to that the general belief in the "power" of deadlines to help with motivation (remember the "T" in SMART goals?), and the result is dates used as "insurance policy".
It has been my experience that in "very date driven" organizations, once you start asking about the nature of the date what you often find is the fear of work taking too long, never getting done, not knowing how much it will cost, etc.
In some organization, this fear is well founded: their delivery systems are unpredictable. In others, however, delivery is much more reliable, but unfit for purpose (taking way longer than people would like). In others, you actually have an acceptable track record, but you're talking to people who have been "burned" many times before in other places, and they just carry that distrust with them to other contexts.
In all these cases, of course, imposing a deadline doesn't really help, but here's where that belief in "dates as motivation" kicks in. Calls for "being less date driven" will not assuage the fear, lack of trust, and bad memories, and this might explain why they also go unanswered, again.
"OK, but it's still annoying. How do we become less date-driven?"
Every business requires some degree of predictability and speed; I'd start by trying to understand what's appropriate for the context I'm in. Then, rather than fighting the battle to convince people to stop "asking for dates", I'd then work to improve the process to achieve the level of predictability and speed that will make that request largely irrelevant.
Becoming more predictable doesn't mean "becoming better at estimation" or "forecasting". If your process is unpredictable (that is, it exhibits a wide range of variation), a better estimation/forecasting process can only give you more unsatisfactory answers (predictions with a large margin of error, or with ranges so wide that are useless). Instead, I'd start by "becoming better at measurement".
It also doesn't mean removing all variation; in knowledge work that won't be possible, and in many cases not even desirable. But you can understand your sources of variation and delay, decide which forms of it are not helping, and then work to reduce its range.
Also, it's not about eliminating all uncertainty. Some knowledge work is all about doing things we've never done before, innovating and learning. The trick consists in delineating decision boundaries into something that it's by nature unbounded; this involves feedback and iteration.
So, in more actionable terms:
Rather than "improving estimation", start by "improving measurement". Start measuring lead time, throughput, quality, etc. Refine the system of measurement based on your interpretation and insights of the results you see.
Understand what is "fit for purpose" in your environment and how that connects to predictability and speed. Are your dates mostly externally driven (and outside your control), or internally defined? what's the cost of delay profile associated with them? Is there any seasonality associated with the arrival of date-sensitive work?
Identify your common sources of delay, and introduce process changes to either eliminate them, or minimize their impact. This will help you with predictability and speed.
Pay special attention to failure demand. Increase quality as a way to reduce it. This will have two effects: 1) it will help you reclaim capacity that can be applied to other work; 2) it will help increasing trust with your customers.
Introduce tighter feedback loops. Practices like Delivery Reviews, Retrospectives, product/work demos, frequent deployments, etc. are a good place to start, but keep in mind that a feedback loop requires more than "inspect" activities; the loop closes when there's reflection and corrective actions are taken.
With this foundation in place, then you can start changing the game:
Find ways to deliver more often. If we can delivery work on a regular cadence, and that cadence is relatively frequent (every week/day/month, etc), then the conversation about specific dates can eventually morph into selecting the most convenient cycle-end date. Also, if you "miss a deadline" in this scenario, then you know when the next delivery window will be. This can eventually help separate scope conversations from deadlines conversations.
Find ways to change (and reduce) the unit of commitment. Another name for this is "reduce the batch size". Your Business is probably accustomed to negotiate work in terms of big projects, and then attach a date to it. Once you have the ability to do frequent deliveries predictably, this can enable offering the business the option to take delivery of smaller portions earlier. Over time, this can teach them also to ask for smaller commitments.
Gradually introduce the idea of different classes of service (Fixed Date Delivery, and Standard), with different delivery expectations and commitment pre-conditions (for example, a minimum submission time to guarantee on-time delivery)
Introduce the notion of different types of work, with different delivery expectations and commitment policies. In particular, separate work whose purpose is to learn and it's more uncertain (call them "experiments", perhaps) and from work that has well defined boundaries (maybe call it "features")
Comments