Business leaders often have legitimate reasons for wanting certain capabilities by certain dates. The key is shifting from ‘no deadlines ever’ to ’deadlines are a constraint we can work with creatively.’
Are deadlines the enemy of Agile? Many teams think so. But while unreasonable deadlines can destroy morale and quality, legitimate business timing needs shouldn’t be ignored. In this episode, we explore how to work productively with deadlines while maintaining Agile principles:
- Why the “no deadlines in Agile” mindset can be counterproductive
- Understanding the Iron Triangle and its relationship to quality
- The counterintuitive psychological effects of fixing time vs. fixing scope
- Practical techniques for meeting business timing needs while maintaining quality
- Real-world examples of successful deadline navigation
Whether you’re a leader trying to make commitments to stakeholders or a team member struggling with deadline pressure, this episode offers concrete strategies for making peace with deadlines in an Agile context.
Contact Us
📧 Share a challenge or episode idea: mailbag@humanizingwork.com
Connect with Humanizing Work:
Episode transcription
Richard Lawrence
In my coaching work, I’ll sometimes hear people say things like, “There are no deadlines in Agile. The work takes however long it takes.” And I get where that comes from.
Peter Green
Yeah, I can empathize. I’ve been part of many big releases that turned into huge scrambles at the end, with mandatory overtime, daily progress reviews with executives, and tons of pressure to get the thing over the finish line, like, yesterday. Internally, people referred to these final weeks of a project using very strong metaphors, like the “end game” and the death march. We also know that when there’s a lot of complexity involved in a project or release, it’s inherently unpredictable, so trying to forecast out a specific date, then deliver on some set of goals by that date, seems tricky at best without the right tools to manage the work. So I can see why a very vocal group in the agile community started beating the “no deadlines” drum.
Richard
But the reality is more nuanced. Business leaders often have legitimate reasons for wanting certain capabilities by certain dates.
Consider this kind of silly example that illustrates the point…
Suppose you have a startup with a revolutionary 3d printed gingerbread technology. So, it’s early summer, and you want to build an ecommerce website where people can configure and order a custom-printed gingerbread house kit.
Peter
Wait, is this a real thing? I’m pretty interested. I’d for real build like a Starship Enterprise gingerbread house and send it to a specific friend I have in mine.
Richard
[chuckles] No, I think I just made it up, but it is definitely a cool idea, isn’t it?
Peter
All right, Humanizing Work Spinoff!
Richard
Listeners, if you know of something like this, tell us about it.
Anyway, if you were doing this gingerbread house configuration tool, there are really good reasons to want some kind of functionality in before the end of November because most gingerbread houses are constructed in those first few weeks of December leading up to Christmas. If you wait until all the functionality gets sort of done by accident when it’s all ready in e-launch in, say, February, sales aren’t gonna be great. There’s a very real business reason to launch something meaningful in late November.
Of course, as we discussed in our episode on “But We Must” management, needing it by November doesn’t make it feasible by November. The need doesn’t create the capability, even if you must. But it also doesn’t make business sense to say “Well, you’ll get it when you get it.”
Peter
So, in this episode we’re looking at deadlines and how to think about them in a practical, sustainable way.
But first, a reminder that the Humanizing Work Show is a free resource sponsored by the Humanizing Work company, where we help organizations get better at leadership, product management, and collaboration. Visit the contact page on our website, humanizingwork.com, and schedule a conversation with us if your organization wants to see stronger results in those areas.
Richard
As we think about this, Let’s start with a classic project management concept: the Iron Triangle. In any project or initiative, you have three variables: scope (what you’ll build), time (when you’ll deliver it), and resources (usually meaning people, though sometimes also including things like equipment or facilities). The iron triangle idea tells us you can’t fix all three of them.
Sometimes quality is also treated as a variable, which messes up the metaphor—the geometry just doesn’t work quite as well with some kind of quadrilateral. Anyway, most everyone agrees quality shouldn’t be a variable, though there’s disagreement on what quality actually means. The irony is that, while quality is explicitly treated as fixed (“we don’t compromise on quality”), when you fix everything else, quality becomes the actual variable: the thing you give up. People cut corners to deliver scope by a deadline.
Peter
In traditional project management, people often tried to fix both scope and time—”We need all of these features by this date”—leaving only team resources as the variable. But adding people to a late project often makes it later, as Fred Brooks taught us decades ago.
Richard
The big insight of Agile approaches is that scope is usually the best variable to adjust. Time might be fixed because of a market window. Resources are often relatively fixed, at least in the short term. But scope… well, there’s usually more than one way to solve a problem.
Peter
And this is where I see teams and product people get stuck. When they hear “deadline,” they assume it means both time AND scope are fixed. But it doesn’t have to mean that.
Richard
Right. Let’s talk about what happens when you fix time vs. when you fix scope, even though mathematically they might seem equivalent.
When you fix scope, saying “we need all of these specific features,” several things tend to happen:
- Teams agree on a date calculated from the initial estimates for that agreed upon scope
- New (or overlooked) scope naturally emerges along the way
- Teams either cut corners on quality to make it all fit or
- Teams move the date later
And when the date gets moved, even if everybody agreed to do it, somehow it ends up feeling like a failure.
Peter
But when you fix time– “we need to launch something valuable for the holiday shopping season”—different behaviors emerge:
- Teams get creative about simpler solutions to maximize the value within the time constraint
- Product people get better at prioritizing and slicing
- Quality tends to stay higher because there’s no pressure to jam all in these specific features
Delivery happens on time because time wasn’t a variable, and even if the scope changed along the way, this usually ends up feeling like a success.
I was once working with a group of teams that had a deadline like this. The VP in charge of that group had worked with several stakeholders to describe a set of features that, according to their models, would deliver a nice chunk of revenue if we could deliver by a specific date.
We assembled the teams that would be responsible for delivery and had a one-day, in person workshop to map out the details. By about 2pm, early afternoon that day, we had a nice full whiteboard of forecasted deliveries, a few dependencies mapped out, and other items estimated. It was quickly becoming clear that the desired functionality wouldn’t be feasible by these teams by the desired date.
Since that VP was in the room and had heard all of the discussions leading up to this point, she was fully on board with the challenge, and didn’t pressure the teams to somehow make it happen. She didn’t go to “but we must” management. Instead, she simply asked “what can we deliver by that date?” The ensuing discussion resulted in a smaller scope, but something the teams felt they could commit to and deliver at high quality. That VP was able to renegotiate that new scope with the stakeholders, and update revenue forecasts accordingly.
If you contrast this approach with what often happens–pressure to deliver anyway, teams doing all they can, but sort of caving to the pressure and trying to make it happen, then that scramble when the project starts to fall apart close to the date. This was a real breath of fresh air to work with that VP and her teams.
Richard
I don’t think we can overemphasize that difference between the downstream effects of fixing scope versus fixing time. Even though the math is the same, in real organizational settings, fixing scope almost always leads to expanding scope and a feeling of missing a deadline or you have to sacrifice quality, while fixing a date and managing scope almost always leads to that feeling that you described, Peter, of working together to maximize value within constraints.
So, what does this mean practically? Here’s our advice for leaders and teams:
First, when you hear a deadline, get curious about the business driver behind it. What makes that date important? Understanding this helps everybody find creative solutions.
Peter
Second, treat that deadline as a constraint on time, not on scope. Start asking “What impact do we want to create by that date?” instead of “How can we get all these features done by then?”
Richard
Third, slice work vertically—delivering thin pieces of real value—rather than horizontally by technical layer. And go after the core complexity first—what’s new? What’s most correlated to the impact we’re trying to create? This gives you more flexibility to adjust scope while still delivering the important value.
Peter
And finally, have an ongoing conversation between the team and business stakeholders about tradeoffs. What’s emerging as more or less important? What creative solutions have we discovered? What scope adjustments make sense given what we’re learning?
Richard
The key is shifting from “no deadlines ever” to “deadlines are a constraint we can work with creatively.” This maintains that Agile value of responding to change over following a plan while acknowledging and even taking advantage of legitimate business needs related to dates.
Peter
If you’d like to learn more about working effectively with deadlines and other business constraints, check out our CSPO and Advanced CSPO workshops. We dive pretty deep into these topics and provide practical tools for navigating them. Visit humanizingwork.com to learn more.
Richard
Thanks for tuning in! If you found this episode valuable, please subscribe to the show and share it with others who might benefit. We’ll see you next time!
Last updated