The Usual Response to Deadlines in Development Teams Causes Delays
The Usual Response to Deadlines in Development Teams Causes Delays
The do’s and don’ts to maximize your chances of meeting deadlines
“We have to integrate a new Customer Relationship Management (CRM) tool in our checkout flow four weeks from now.” I heard Vivian, our Product Owner, say.
I was the Business Analyst on the Scrum Team and I responded with: “Why the hurry? This is the first time we hear about it. Why does it suddenly have to be finished four weeks from now?
We don’t know how difficult it is nor what we have to do, yet we already know for sure it has to be done in 4 weeks? How does that make sense?”
Vivian responded: “Well, the business decided to cut costs and cancel our current CRM provider this month. Otherwise, we’d need to extend our contract and be stuck overpaying them for another year.”
I responded: “Okay, I get it, but I assume this is a long-term contract we signed many years back. Couldn’t we have planned this? Someone’s lack of planning now becomes our problem? We’re with our back against the wall and have no option but to deliver. Failure to meet the deadline means we’ll have no CRM system as our contract has already been canceled. Except we can’t be blamed for not having a plan B.”
Vivian gave an annoyed glance and said: “It is what it is. Let’s make it work!”
Deadlines: the looming pressure we love to hate
And that’s the true story of how my team ended up as the proud owner of a deadline without a clue if we could make it. For those who wonder, we did make it but I wasn’t always as fortunate.
I want to stress, there is a difference between not meeting a timeline and not meeting a deadline. In the context of this article, I’m talking about a deadline with immediate and disastrous consequences if we fail to meet it. I’ll still refer to it as a timeline to switch things up.
I’m not talking about timeline pressure in the context of being late due to a problem simply being more difficult than originally anticipated. This simply means our flawed expectations on timelines create a perception of late delivery. The work still takes the same amount of time regardless of the accuracy of your estimate.
Now let’s get back to deadlines. Over the years, many deadlines have been thrown over the fence at me to meet with one or more teams. Even with contracts signed together with timelines I had to meet without being involved in any way. As a Product Owner, I’ve also been on the other side — the evil one communicating the deadlines.
I dislike obsessing over: ‘When will it be done?’. Obsessive focus on meeting a deadline often moves the delivery of value to the backseat. However, there is more nuance on this topic to be explored. Sometimes you’re in a situation where you do have a deadline you need to meet that isn’t self-imposed.
For example, not meeting said deadline would result in terrible financial consequences for the company. And in those cases, clinging on to an idealistic distaste for timeline pressure won’t help you deal with the problem at hand.
When teams are faced with a deadline they need to meet, they often fall back to anti-patterns and kneejerk responses that only decrease the chances of meeting the timeline.
Let’s go through the four steps of the typical reaction of teams when faced with a looming deadline:
Write down all requirements.
Break down everything and estimate with the team
Forecast timelines with scope
Reduce scope, quality or add resources to meet the deadline.
This approach doesn’t work and increases the risk that you won’t meet the deadline, for reasons I will get back to later.
What should development teams do to maximize the chances of success when faced with an impossible deadline? What should development teams not do to prevent slowing themselves down?
I’ve met crazy deadlines and I’ve also failed to deliver by many months. I’m sharing the do’s and don’ts of meeting deadlines based on more than ten years of experience to hopefully prevent others from developing the same deadline scar tissue as I have.
Let’s get down to business with the do’s and don’ts of meeting deadlines!
Don’t: set a deadline without buy-in
I remember working at a fast-growing scale-up where the CEO set a deadline for a new product to coincide with his birthday. I imagine he must have thought: “How cool would it be to celebrate the launch of this new product on my birthday?”
Was the timeline feasible? Absolutely not.
Everybody in the tech department knew we would never make it and nobody was motivated to work their butts off to meet the crazy timeline. The impossible deadline demotivated everyone right from the start. If failure is inevitable, there’s no point in giving everything.
You can’t always set a deadline. Sometimes a deadline is determined by something out of our control, like in the CRM deadline example at the start. Then we have to deal and live with it.
But often, we can decide on the exact timeline together and that’s what we should be doing. This way, everyone will be more motivated to try and make it work.
Even if we set an unrealistic timeline, it will be our unrealistic timeline. People are naturally inclined to own and try to fix their ‘mistakes’, at least to some degree.
An unrealistic timeline set by the business will drain energy as everyone will feel like a victim where others are to blame and they have to clean up their mess.
If outside factors dictate the unrealistic timeline, then clearly communicate what these are and why meeting the deadline is important for the company. And then still try to get buy-in so everyone will be motivated to give everything.
And let’s be honest, most crazy deadlines are dictated by outside factors like the company running out of money or losing a whale of a customer. That still doesn’t mean you can’t obtain buy-in from your teams to try and get them to give everything they’ve got.
Do: identify biggest risks and unknowns
When you do complex work, you’re limited by the fog of beforehand — what you can know before starting the work. Work together with the Scrum Team to discover what are the biggest concerns, risks, and unknowns.
Don’t spend hours talking about it, as you’re limited to the knowledge you can have before starting. What you should do is use this information to prioritize your work to maximize your chances of meeting the timeline.
When you have a crazy timeline you need to meet, you need to find the right balance between delivering what’s valuable and discovering obstacles in your path that will ultimately prevent you from delivering something valuable that works.
It’s better to finish something that is imperfect early than not to finish something that would be perfect if only we had finished it on time.
Don’t: trust your estimates
The work still takes the same amount of time regardless of the accuracy of your estimate. Estimates are guesses which you shouldn’t trust.
Every day you work on meeting that deadline, you will gain more information. Don’t get lulled in a false sense of comfort by looking at your past (a priori) estimates you made before starting the work.
Update your forecasts as you learn more. Realize that what you don’t know will lead you to face new problems and create new Backlog Items that haven’t been created or estimated yet.
When you steer based on your current estimates you need to be aware they are wrong and can’t be trusted. What you don’t and can’t know before doing the work might be lurking around the corner and blow up the whole project. When your forecasts show you will be finishing just in time, probably you won’t be finishing on time at all.
Focus on doing the hard things as soon as possible that may blow up the estimate of the whole project and force you to revisit all your plans and forecasts.
Do: deliver something that works early
As Woody Zuill has written:
“It is in the doing of the work that we discover the work that we must do. Doing exposes reality.”
If you have three months to deliver a project, try to deliver something that works in the first month. By having something that works, the reality of the work is exposed.
It’s appealing to talk, analyze, design, debate, and do infinite research before starting the work to abolish all uncertainty and risk. However, no matter what you do, you’re still limited to the knowledge of beforehand: what you can know before starting the work. You quickly experience diminishing returns from trying to draw conclusions based on inadequate information.
There is nothing worse than being 90% done, deploying to Production for the first time, and suddenly realizing you’re only 70% done because you missed some critical things necessary to go live. Deploying to Production ensures we have something that works and increases the confidence we didn’t miss anything. There always is something that breaks or doesn’t go as expected.
Here’s an example of a horror scenario I personally witnessed due to deploying to Production late. I worked on a project that was delivered on time and worked perfectly in an acceptance environment with the same data and set-up as Production. The only difference between Production and Acceptance was the language of Sharepoint.
When we deployed to Production nothing worked. We discovered that the English API calls did not work in the Dutch version of Sharepoint. The Dutch version was expecting API calls in Dutch instead of English.
Who the hell could have seen this one coming?
Someone at Microsoft decided to localize their API endpoints. I wish I was making this up.
I still wonder what problem they were trying to solve, as English is the unofficial second language of the Netherlands. Also, it would be impossible to find a Dutch developer who wouldn’t be able to make API calls in English.
Don’t: break everything down to forecast a timeline
Our usual response to produce a better estimate is to sit endlessly in meeting rooms and break everything down to the smallest detail.
By doing this, we lose valuable time we could spend actually doing the work. As stated before, this is where you discover the problems that matter. On top of this, all those elaborate plans are detached from reality and will ultimately function as quick-sand that slows you down more and more as the project goes on.
Sticking to the plan as it deviates more and more over time is a dangerous thing. It is better to start with simpler plans that are easier to adjust as a result. When you break down the whole project to the smallest details, at least now you can fool yourself that you have a better idea of how much later the project will be delivered.
Make lightweight plans with the right balance of delivering value and discovering what we don’t know yet. It’s a tricky tightrope to walk and we have a natural tendency to overfit our plans and assume we know more than we actually do.
What you don’t know and believing you know more than you do is what makes our plans fail.
Plan the first few steps, and only make a skeleton for the rest. Then as you perform the first few steps, expand on the skeleton of your plan based on what you discover and learn. Don’t be afraid to add more detail as you go along, because the detail you add later is rooted in reality and not only in your imagination.
Do: ruthlessly keep things simple
When faced with an immovable deadline you have to meet, start with making decisions on the kind of shortcuts you’re willing to accept. The time you lose now, you won’t get back later when you do need it.
The best thing you can do is to ruthlessly work to keep things as simple as possible. Do we really need this feature? Are we building the new system in the technically simplest way? If we make it simpler, what problems could we run into? Are we willing to accept those problems and can we fix them later or would it mean rewriting large parts of the new system?
When you work in tech, you’re probably familiar with the following quote:
“Premature optimization is the root of all evil.” — Donald Knuth
If you want to prevent premature optimization, you need to deliver things that are too simple. Reality will expose your solutions as too simple and then force you to think about what you should do to improve them. Emergent design is the enemy of premature optimization. If you don’t encounter problems, you can’t know if your solution is too complex. As a result, you’re likely suffering from premature optimization.
You should also talk about quality. Could we accept lower quality for now and add polish later to ensure we meet the timeline?
Of course, explain that adding quality later will take more time than if we do it now. It may be worth it if it means the difference between delivering on time or not delivering.
Lowering quality is not the first avenue you should pursue, but nothing should be off the table if you have a deadline to meet, which would cost the company significantly more money than the technical debt you’ll introduce to meet it.
Do: design a system to fit the constraint
In the article, ‘The Tyranny of The Plan’, Mary Poppendieck explains how the Empire State Building was delivered on time and 18% under budget. There’s way more to it than I can do justice in a few sentences, but the most important insight is the following:
“Design the system to meet the constraints, do not derive constraints from the design.” — Mary Poppendieck
When building the Empire State Building, the biggest constraint faced during the construction was the flow of materials — getting all that steel and concrete in the building as fast as possible.
Two main factors contributed to this constraint:
1. In the 1930s, all construction had to take place during the daytime, as there were no floodlights yet. Having to obey the circadian rhythm meant trucks with materials had to go back and forth during the day in dense New York traffic.
2. There was no place to store all the materials in Manhattan for such a tall building, so everything needed to become part of the building as fast as possible. By making all materials part of the building immediately, there was no need to store materials at a location external to the building site.
To guarantee the flow of materials they decided on decoupling workflows as much as possible, so delays in steel, concrete or windows, would not cause compounding delays. Anyway, read the original article if you are interested because it is explained much better there.
In short: design the system to meet your constraints, do not descope the system based on the constraints in your design. If you don’t know your constraints, build the simplest system possible to discover your constraints.
No matter what we do, meeting crazy deadlines will always be tough
There’s no magical formula to meet an insane deadline. However, by being aware of these do’s and don’ts, you can maximize your chances of success.
Instead of jumping in a meeting room and endlessly debating, start talking about what’s the simplest thing we can build where have some doubts if it will work.
Your doubts may turn out to be true, worse, or not as bad. There may also be other doubts you hadn’t considered yet, which you’ll be happy to discover sooner rather than later.
By doing the work, reality is exposed. No matter how much time you spend in meeting rooms discussing, analyzing, and planning, when you do complex work there’s no way your plan will survive a confrontation with reality.
Test, shape, and mold your plans by confronting them with reality. Build the simplest thing possible you can’t imagine will work and use that to figure out what is necessary to make it work.
Work with what you do know to figure out what you don’t know. The biggest danger is we assume to know more than we actually do.
Over-thinking shrouds reality with mental fog, doing reveals what is hidden by the fog of beforehand.