You’re Dead to Me!
Can we please stop perpetuating the “there-are-no-deadlines-in-Scrum” fallacy?
Years ago, when I first dipped my toes into the water as a newly-minted Scrum Master, I overheard a conversation between my then-company’s only Certified Scrum Master (CSM), and a project manager (PM). Back then, my department went through the obligatory 2-day Scrum training session facilitated by an outside consultant. When it was all said, and done, the PM asked in a side conversation how to approach deadlines in this “new agile process.” The CSM responded with, “There aren’t deadlines in Scrum.” You can imagine the PM’s reaction. To this day, I still hear similar statements.
“Deadlines aren’t compatible in Agile environment.”
I call bullsh*t!
First, let’s start off with what constitutes a deadline; it can mean different things to different people. Are they arbitrary target dates that, fingers crossed, you can hit? Are they an uninformed promise made by an overzealous salesperson? Or are they dates derived based on realistic scope, predictability, and the truthful capability of the team?
If you’re a stickler, I’ll concede that neither the guide we consider canon, nor the Agile Manifesto mention the word deadline. Thank goodness that we don’t have to live in Microsoft Project (MSP), or produce elaborate Gantt Charts (gross), but like it, or not, deadlines are a reality. Some organizations may be obligated to hit federally-mandated dates, or face heavy regulatory fines, and penalties for missing them. So, vomiting dogmatic rhetoric about the incompatibility of deadlines isn’t doing your organization any favors, nor their buy-in of Scrum.
It’s certainly my opinion, but Agile is more of a philosophy — at least that’s how I see it. And Scrum is simply one way to apply that philosophy. Sure, it’s fundamentally about change, but it’s also not necessarily about abandoning every existing construct altogether. Small, incremental change; sound familiar? Are those who perpetuate the incompatible deadline fallacy missing the point?
“Dates are real. Pretending they aren’t is living in a fantasy world. Seriously. I really don’t understand this insistence on we just deliver value and magic occurs. Value after a hard date isn’t value. It’s complete and total waste. Understanding what scope a team or team of teams can deliver by a date is great information. But Scrum is about producing value quickly. If you can’t hit a date, I care not at all what process you are using, your team has become superfluous.” — J.J. Sutherland on LinkedIn
Using Scrum to your advantage wasn’t about wiping out the notion of deadlines, rather how we approach them. I’m not the first to cover the notion either. Check out Predictability in Scrum, a goal or a means? by Marty de Jonge to get a taste. But I wanna go another direction here. The following contrived conversation is an oversimplification, but it illustrates a typical scenario.
- Stakeholder: “We need this stuff by this date.”
- Scrum Master: “Great, here’s what the team is capable of delivering. To hit your date, what fat do you wanna trim, or what can be dropped altogether?”
- SH: “Nothing. All of this is MVP, and the date is set in stone.”
- SM: “OK, if the scope of your ‘MVP’ is humongous, and can’t be adjusted, and the date is unmovable, would you prefer the truth about being late, and/or over budget now, or months from now when it’s too late?”
Truth is truth. It demands that you actually know what your team is capable of (throughput), and have the discipline, and foresight to adjust accordingly. Scope should be flexible. It’s like Scrum forces you to perform project management the right way. Balancing infinite requests against limited capacity is basic project management, but are you ready to shift your thinking, and move beyond the basics?
Remember that bit in the Manifesto about technical excellence? With that in your back pocket, could you use it to make deadlines a non-issue? And I don’t mean by insisting that they don’t exist. By adopting Scrum, you’ve most likely changed development practices. I won’t dispute that Agile was created for developers, by developers, but I see it as a philosophy that you can be applied to several realms, like deadlines. Shift your thinking. Rather than metaphorically suffering like Prometheus in a never-ending cycle of “we gotta hit this date,” I’ma give another callback to technical excellence.
Let’s take a moment to hop in the time-traveling DeLorean with Marty McFly. Remember before WYSIWYG editors hit the scene? Back in the day, updating content on a web page required developer time. Nowadays, we take creating blog posts, correcting misspelled text, or uploading images by ourselves for granted because content management systems (CMS) are so prevalent. It took a change in thinking to grant that capability to end users. By shifting this paradigm, the responsibility moved away from developers, and deadlines for updating content became a non-issue.
I’ll say it once again, shift your thinking. Identify what influences your ability, or inability to hit a deadline. Are there manual processes that can be automated? Are deployments, or releases to production governed by a third-party committee that enforces an old school “Go/No-Go” policy? Do updates to your product, no matter how small, require developers to write, and deploy code? Can anything be configuration-driven? All of these (and more) affect deadlines. Where can you identify candidates for change?
“It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be.” — Isaac Asimov
So much of being a Scrum Master is about people, and psychology, but we tend to silo our thinking down to a singular view. We sometimes forget that change needs to happen at a philosophical level, beyond the team, and conceptualize at a system level. Deadlines probably won’t be going away anytime soon. However, if you tackle them philosophically, like what WYSIWG editors did for content updates, maybe deadlines can become a non-issue, and no longer a part of the conversation on whether they can be met.
So, let’s work together to put an end to all this nonsense about deadlines not being a thing in Scrum. Maybe then we can focus on the things that truly matter.
</rant>
Many thanks to Sjoerd Nijland and Marty de Jonge for their awesome feedback on this post.
