Can Agile and deadlines coexist in perfect harmony?

Managers, this one is for you.

More and more these days, I’ve been hearing this sentiment from managers in the organizations I coach:

“We have hard deadlines, so Agile can’t help us.”

My typical reaction ranges from astonishment to bewilderment. Considering the number of times I have heard this type of statement, my level of surprise should diminish. But instead, my shock persists.

After all, Agile methods are a strategy to reduce risk. Agility requires early knowledge acquisition and our rapid response to it. So, I have a hard time reconciling why managers would feel Agile can’t work in the context of a hard date constraint.

I’ve been part of many teams who deliver with agility amidst a date constraint. To achieve this, they focus on high-quality value flow to meet goals sooner in a sustainable manner. The behaviors of these teams have deep roots in Agile values and principles.

Now, if you follow my writing, you know I’ve written at length on the problems with fake deadlines. If we manufacture a deadline to motivate teams, everyone loses. But I firmly believe if you have a legitimate date constraint, Agile methods are your best bet for success.

As I pondered this situation, I captured seven ways I’ve seen agility help teams meet a real date constraint. I’ll reveal these later. But first, let’s explore why managers feel Agile and hard due dates are enemies instead of friends.

Here are some reasons why managers feel Agile and deadlines are enemies

I see two key reasons driving managers to see Agile and deadlines as archenemies. First, managers are uncomfortable with the unfamiliar. And second, managers view the lack of a detailed estimate and plan as a weakness.

Problem 1: Managers trust what they know

Agile is now over two decades old. But in many ways, it is still brand new to many organizations. You will find most managers in these organizations have careers absent of Agile. All they know are traditional, phase gate-based, big-batch, command-and-control delivery methods.

Many of these managers have been successful in hitting a deadline using traditional methods. But in doing so, they often leave behind a swath of collateral damage, such as:

• Overproduction of features to meet a stakeholder promise but not needed by customers
• High levels of technical debt incurred in favor of meeting the deadline
• Piles of lower-priority defects left behind and unfixed
• Reduced levels of automation for routine, repetitive tasks (like tests) because “we ran out of time.”
• Lower team productivity due to all the quality compromises
• Worn-out teams, driven to an unsustainable pace to meet a deadline at all costs
• Lower transparency as teams and managers begin to hide the corner-cutting
• Reduced team psychological safety: “Don’t bring me deadline problems, bring me solutions!”
• Diminished time or space to innovate or improve the product or ways of working
• Team members are apathetic to autonomy as they are handcuffed to a plan with strict orders to follow it

When hitting a date is the goal, it becomes the only thing that matters. Many see collateral damage as a necessary evil in the service of delivering on time, at all costs. But the shortcuts are a local optimization with long-term, compounding, disastrous effects.

Ironically, Agile was a response to the damage inflicted by traditional methods. The same is true of empirical frameworks like Scrum and Extreme Programming.

Agile did not emerge to ignore deadlines. Rather, it emerged to embrace change and deliver timely value — without the damage.

Despite this, many managers remain skeptical of Agile methods. Their doubt is not surprising as Agile turns a manager’s world upside down. Agile behaviors are counter-intuitive, unproven to them, and foreign to their experience context.

Believing in Agile methods takes a giant leap of faith for these managers. The only way for them to begin to believe is to try out the new ways and inspect the results.

But with a deadline looming, the risk to try something new is too great. Most of these managers will retreat to what they know.

Agility does not stand a chance in this context. It is a foreign element, untrusted and unproven against the old ways of working. Managers label Agile as incompatible with deadlines and reject it before trying it.

Problem 2: Managers see learning-forward approaches as too “squishy” for the real business world

Traditional ways of working emerge from a stance of, “I know,” instead of, “I don’t know.”

Many managers incorrectly treat product development as a knowable, yet complicated, problem. They believe they can devise a pristine set of requirements, design, and plan up front. Then, teams must follow the plan verbatim, and all will be well.

These managers view an inability to predict with precision as weakness or ineptitude. They often don’t trust their teams can do it well. So, they put estimation and planning in the hands of their most experienced team leads. But these leads rarely do the work, and their estimates are often unattainable for the teams who do.

The team leads who estimate have to protect the belief in their estimation prowess. So, they drive the teams relentlessly to commit to and deliver on the estimates. This vicious cycle exhausts teams and strips them of autonomy. It is not sustainable.

Even worse, when teams inevitably fail to deliver, the investigation begins. Blame is sought. The system has no tolerance for non-compliance to the exact steps needed to hold to the upfront plan.

This game of baselining early locks teams into a plan at the moment of the highest uncertainty. As such, it fails to acknowledge the unknowable aspects of product development. Scope, technology, and human variability fuel the futility of premature plan convergence.

But if teams point out this risk, managers tend to dismiss it out of their fear of losing control. No manager wants to own a ball of uncertainty and potential chaos. After all, managers are here to manage.

“Details in planning and estimates inspire confidence.”

— A quote from a manager unfamiliar with agility

When faced with the unmanageable, many managers feel compelled to appear in control. They seek detailed plans and estimates as an antidote to the uncertainty.

But amidst complexity and uncertainty, plans and estimates are an illusion of control. Control is a fiction in the reality of product development.

But many managers press forward seeking control. They set the deadline and scope. Estimates and plans are set in motion to deliver all scope by the deadline. And they drive the teams hard to follow the estimates and plan.

When everything gets fixed in service of the deadline, the deadline, regrettably, becomes the goal.

How Agile and deadlines can be friends

Yes, agility can co-exist with deadlines. I see no better way to work in the presence of a real date constraint. Let’s unpack this a bit with my seven guidelines below.

1: Put your customers front-and-center

Delighted customers don’t talk about how well you delivered on time. Instead, they gush about how well your product improves their lives. In this truth, lies a key to how Agile and deadlines can be friends.

For some reason, when deadlines are in play, the customer gets lost in the mix. We converge too early on scope up front. A plan to deliver all scope we can dream up on schedule becomes our focus.

After all, engaging with the customer could interfere with our plan to deliver on time, so we don’t do it. In turn, we miss the opportunity to get customer feedback and adjust course along the way. Instead of being customer-centric, we become deadline-centric.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

— 1st principle of the Agile Manifesto¹

Alternately, if you can keep customers close and at the core of your focus, you can deliver impact early. Partnering with your customer ensures you focus on the essential in the time you have.

Continuous delivery means customers do not have to wait until the deadline to get some value. They can use features early and begin reaping value sooner than the due date. Return on investment starts, and as a result, deadline pressure fades.

And if the early increments are not quite right, users can give feedback to adjust course along the way. Continuous customer feedback helps simplify, clarify, and focus on what you need to build:

• “Don’t go any further with this solution as it is not working for me.”
• “This solution is just right, we don’t need to enhance it further.”
• “This solution needs just a bit more to meet my needs.”

Involving customers before, during, and after delivery helps you arrive at the right thing sooner without excess.

A customer-centric approach such as this makes me question the usefulness of deadlines. When we harvest value early in the timeline, do deadlines still matter? Do we still need them?

2: Engage whole teams end-to-end

The quickest way to put a deadline at risk is to strip away control from your teams and give them only a small part to play. I’ve seen this take many forms, and all steal away team autonomy, mastery, and purpose:

• Splitting strategy, discovery, design, delivery, testing, and operations into separate teams. Each team is then responsible for different phases of work.
• Segregating front-end, middle-layer, and back-end development functions into different teams.
• Separating project management from the team to a group who directs the team members on what to do, when to do it, and how to do it.
• Having product managers do product strategy and direction in a vacuum without the teams.
• Relegating customer interaction to a customer research team or marketing team.
• Having a separate intake team generate, estimate, and prioritize all work for the team to perform.
• Putting technical design only in the hands of the technical leads.

A team’s engagement plummets when it only owns a small part in getting an idea to a customer. If you are looking for a future predictor of team effectiveness, look no further. Low engagement — a measure of a team’s autonomy, mastery, and purpose — guarantees low effectiveness.

“I think people get satisfaction from living for a cause that’s greater than themselves. They want to leave an imprint.”

— Daniel Pink²

So let’s avoid this trap. Instead of single-specialty teams in silos, create complete, cross-functional, empowered product teams. Engage them in the entire end-to-end value stream. Give them the right environment, support, and trust, so they can get their job done.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

— 5th principle of the Agile Manifesto

Plus, when you remove the silos, all the waste they cause diminishes. Here are the lean wastes you won’t miss:

• Hand-offs: If your team owns work end-to-end, hand-off waste fades away.
• Waiting: To complete its work, a whole team doesn’t have to wait on other teams to first complete their work.
• Multitasking: When the entire team focuses on the same thing together, context switching costs drop.
• Defects: When diverse team members work as a unit, they build in quality and prevent defects.
• Work-in-progress: When teams focus on one thing end-to-end, the amount of work started but unfinished plummets.
• Over-production: When a team has everyone focused on a common goal, less gold-plating and just-in-case features get built.
• Over-processing: Coordinating all dependent teams to deliver on time is a waste you won’t miss.
• Relearning: The whole team is in the same context, so the waste of relearning after hand-offs diminishes.
• Wishful thinking: You don’t have to hope things are going well when one team owns all aspects of the product. Their progress is transparent and obvious.
• Knowledge scatter: Knowledge stays in the team and transfers fluidly between its members.
• Under-realizing people’s potential: When the team owns end-to-end flow, you tap into the diverse minds of each team member at every step of the journey.

So if all the wastes above reduce, do you think the team will be better positioned to meet a deadline? You bet it will. Without the added weight of silos, deadlines are not a problem.

The best architectures, requirements, and designs emerge from self-organizing teams.

— 11th principle of the Agile Manifesto

When you have decentralized ownership, you have power in numbers. If every team has and exhibits end-to-end ownership, you have a much better chance of success.

Alternatively, putting ownership in the hands of a few program orchestrators is risky.

So, when you have a deadline, you want all minds and hearts in play and on the same team. It’s your best bet.

3: Cut inessential scope, not quality

In most cases, quality is the first thing to get cut when a deadline is tight. And poor quality has many nasty side effects:

• You lose face (trust) when defects slip by undetected.
• Low-quality code slows down future work.
• The longer the life of a defect, the longer it takes to fix it.
• Defects unfixed tend to invite more unfixed defects due to quality apathy.
• When you reach the deadline, your product may not meet the bar to ship
• Your transparency reduces as you create optics and excuses to obscure low quality

Instead of compromising on quality, cutting scope is a better path. But when facing a deadline, many have trouble reducing scope. Everything tends to become a must-have feature.

I’ve found this happens because deadlines feel like the last chance to deliver a set of features. It seems like an all-or-nothing situation. And if the scope can’t budge, quality will.

In my experience, breaking this pattern requires a shift in focus from output to focus on goals. First, think about what the customer needs and where they feel pain. Then, focus on the simplest solution to solve the goal.

Simplicity — the art of maximizing the amount of work not done — is essential.

— 10th principle of the Agile Manifesto

Focusing on simplicity will help you move through a progression of good, better, and best scope to meet the goal. If you can deliver a good solution first to meet the goal and beat the deadline, you win.

So don’t fall into the trap of thinking everything is a top priority when staring down a deadline. The best solution you can imagine may not be what your customers need in the time they need it.

When you simplify your solution, you simplify the path to meeting your goals by a deadline.

4: Keep a steady, sustainable pace

When staring down a deadline, fear of missing it can drive teams to work at an unsustainable pace. If your teams become exhausted from running all out, they will not be able to finish the race in top form. And they will not be ready when the next race starts.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

— 8th principle of the Agile Manifesto

Keep an eye out for signs your team’s pace is becoming unsustainable. If team members begin to burn the midnight oil, skip out on life, or neglect their well-being, it’s time to reflect and adjust. You need to find a more sustainable method.

This could include:

• Simplifying what you are building or how you are building it.
• Prioritizing the aspects of your solution to focus on critical elements first.
• Removing lower impact or unnecessary features from your scope to reduce distraction.
• Honing in on today’s problems, not tomorrow’s.
• Engaging teams with your users more frequently to speed up feedback and stay on the right course.
• Focusing on finishing one thing at a time before starting something else.
• Amplifying collaboration to tap into the power of the team.

Burning the candle at both ends is risky and not compatible with meeting a goal by a deadline. Don’t drive your teams to do it. Simplify, focus, and support a steady pace instead.

5: Use evidence, not wishful thinking

In your complex, uncertain domain, you must face a key but uncomfortable truth. Here it is: plans are useless. You can’t bet on them, and any behavior to do so is nothing more than wishful thinking.

Wishful thinking is a lean waste. When you do this, you waste time hoping for the best and holding on to your stale plans. You fall prey to waiting on a miracle to make them true.

We spend long cycles planning, estimating, and designing up front. And we don’t want all this time and effort to go to waste. We get seduced trying to squeeze value from this sunk cost even when it is obviously not going to happen.

When you hold on to a bad plan and false hope, your deadline is at risk.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

— 2nd principle of the Agile Manifesto

Your time is better spent taking action to learn from evidence and adjusting to reach your goals. But pivoting is not equal to panic. A measured approach to responding to change is critical.

To keep panic at bay, inspect evidence and apply course corrections daily. This frequent learning is your best bet to meet your goals and keep a sustainable pace.

So, stop wishing on a star, and chart your next step based on what the data is telling you. Do this even if it means throwing out your prior hard-earned plans and work.

Meeting a deadline relies on your ability to move with quick, easy grace in the face of new information.

6: Favor action

I find it interesting how deadlines cause us to double down on planning and estimation. We think if we can devise the perfect plan, all will go swell. But it never does.

Taking action beats a perfect plan. We learn from action, not planning. With learning, we make progress and clear the fog obscuring our path.

Working software is the primary measure of progress.

— 7th principle of the Agile Manifesto

Here are some quick ways to favor action over upfront, risk-averse, predictive planning:

• Instead of detailed estimation, start doing the work to learn how difficult or easy it is.
• Test a low-fidelity sketch of a solution with a customer for fast, inexpensive insights.
• Try out two approaches to see which one is best.
• Instead of planning out every detail in advance, set goals and experiment, learn, and adjust daily to get there.

When we take action, we get feedback on how well our action worked. We see firsthand if it got us closer or farther from our goal. In short, we learn by doing how long the work will take.

“It is in the doing of the work that we discover the work we must do.”

— Woody Zuill

So next time you feel compelled to estimate and plan it all out up front, stop. Instead, brainstorm actions you can perform today to get you closer to your goal. Then, take a small step in that direction, inspect your results, rinse, and repeat.

When you act and reflect after each step, you can learn the shortest path to your goal and your deadline. And you won’t waste valuable time on a big upfront plan and estimate.

7. Work small with a goal in mind

Many of the other recommendations touch on this one. Working small is your friend when you have a deadline.

I’ve seen many organizations get busy, really fast, when a deadline is looming. Getting all scope done by the deadline drives them to start too much at once. They take larger steps and as a result, slow down the feedback loop.

And the goal of the work — the outcomes we are targeting — gets lost when we fixate on the scope. With larger batches of work, there are fewer chances to adapt to meet your goal. Unfortunately, the goal becomes getting all the work done by the deadline all at once.

But if we can take many small steps, we will be able to re-orient after each step to ensure we are still pointed at the goal. Taking a small step allows us to pause and reflect on both the benefit of the step and the approach we took to take it. The course corrections from these rapid feedback loops help us better meet a goal by a deadline.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

— The 12th value of the Agile Manifesto

Remember, delivering everything by a deadline is not the goal. Rather, the goal is to solve customer and business needs in time to benefit from them.

Small adjustments along the way help us deliver the right thing in the right way at the right time.

Taking it forward

Many managers see deadlines and Agile as enemies. These managers tend to trust their experience with predictive methods. They see Agile methods as counter-intuitive. Agile’s focus on learning as you go seems too soft and does not provide something for managers to manage.

But the good news is agility can co-exist with deadlines. It can reduce the risk of not meeting a due date with a useful solution. There are at least seven ways Agile can be friends with deadlines:

1. It ensures you are customer-centric.
2. It engages all team minds in the task.
3. It helps you trim the unnecessary.
4. It encourages you to keep the pace reasonable and sane.
5. It helps you not bet on hope.
6. It urges you to favor trying and learning over planning.
7. It promotes frequent adaptation to meet a goal.

Here’s a secret to take away. The ways Agile reduces risk hold regardless of the existence of a date constraint. Agile does not care if you have a deadline. Customer-centricity, rapid feedback, learning by doing, adaptation, focus, and collaboration apply…regardless.

You may have noticed the Agile principles quoted among the seven ways Agile and deadlines can be friends. This speaks to the compatibility of Agile and deadlines.

You can take this notion further by looking at the four Agile values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

— The four values of the Agile Manifesto

Does the presence of a deadline obviate the need for these four values? I contend it does not, based on my experience. These four values accelerate our ability to meet customer needs sooner. And this matters the same whether we have a deadline or not.

So, join me in helping Agile and deadlines be friends. What will you do to go all-in on Agile values and principles? How will you increase your agility to deliver high-quality value sooner at a sustainable pace?

For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.

Related Posts

You can read similar posts by the author below:

References

1. Agile Manifesto for Software Development, Beck et Al., 2001
2. Drive — The Surprising Truth About What Motivates Us, Daniel H. Pink, 2011