You’re Doing It Wrong: Deadlines

This series is about practices we do, without understanding why we do them, and therefore may not get the value we want from them. If you too don't benefit from them, you might be doing it wrong.
Iteration planning, Pt. 1 Iteration planning, Pt. 2Definition of doneDemo
Done-DoneDaily stand-upsRetrospectivesContinuous integration

We know that deadlines drive behavior. That’s why in scrum, and other agile methodologies, we timebox the development with those deadlines. They tell us: Focus on the important stuff, and make sure it’s done properly.

Since they are good in essence, let’s see how we muck them up.

Here’s the process. We prepare for the sprint, splitting stories, asking for details and estimating. After all this effort, we decide it’s safe for the story to enter the sprint, because we’ll be able to deliver it.


Things happen.

We discover new stuff, hidden details. We also find out unplanned tasks creeped in. The deadline is looming. We won’t be able to make it…

Imagine the horrid humiliation of not meeting our own estimates. How can we face our peers with the late result of doing something for the first time, and missing the mark completely? What will they think of us?

So we cut corners. We skip unit tests. We skip the code review. We decide the story is small and doesn’t require proper design review. We push the code to trunk, and hope that testing can occur before we the clock runs out. And maybe we’re lucky, and we can count the story as “done”.

Cool, we got our story points. Party time!

Ironically, it’s what agile always wanted: Individuals and interactions over processes and tools. We throw the process out the window to please people (and ourselves).

Fear factor

Yeah, it’s the old story of deadlines rolling over us, again and again. But why do we let them? (assuming these are not actual business deadlines, just end of sprint, or even releases?)

  • Deadlines are simple. They are so much easier to explain and understand than doneness.
  • Deadlines are objective. Doneness is subjective.
  • Deadlines are always visible. Doneness is only visible when checked.
  • Deadlines don’t change their meaning. Doneness changes all the time.

We are more comfortable with deadlines because we’ve lived with them all our lives. We make the best we could to abide by them, usually by dropping quality to meet them. In most cases we got a pat on the back by meeting them, and a slap in the face when we didn’t. Regardless of quality.

We’re comfortable to prioritize deadlines, even self-dictated, imaginary, ineffective deadlines over everything else. Are we supposed to put quality, or doneness, whatever you want to call it, over them?

And now we’ve got that pesky scrum master chastising us about those “doneness things”. Still, when we look over the table, we see a satisfied product manager. He tells us, “that’s ok, you can do the code review later”.

The defense rests.

Changing the behavior

We like to talk about mindset, how we can shift it in a better direction. The bad news are, I cannot change yours, by downloading mindset 2.0 into your brain. God knows I tried.

The way we change is by how we perceive other people’s behaviors. If management and teammates change their behavior, there’s a good chance I will too. If we start rewarding doneness, and start saying out loud:

  • Yes, it’s good that you haven’t pushed this into the trunk and risked everybody else’s code
  • Yes, it’s good that you waited for that code review because we found 2 bugs that could have gone into production
  • Yes, it’s good that you’ve written those tests, because now we move to other features depending on yours without fear of rework
  • No, it’s not good that you’ve skipped the design review because we’re finding now, that we either need to stop other team’s work, or go back to the drawing board
  • No, it’s not good that you skipped the automatic tests, because now we need to do a manual regression suite every time.
  • No, it’s not ready for production unless everyone agrees it is based on what we agreed, and it clearly isn’t.

Until we start behaving like doneness matters, the mindset will not change, and worse – behavior won’t change. Deadlines will continue trumping quality. Only if we let them.

4 comments on “You’re Doing It Wrong: Deadlines”

  1. David V. Corbin Reply

    “Ironically, it’s what agile always wanted”… NO it is not… There is a key difference between “over” (as per the manifesto) and “to the exclusion of” (unfortunately common)… “The items on the right have value”!

    Moving something into a sprint is a commitment, but commitments change (ask any parent who ever committed to some event and had to then break the commitment). The key point is to raise awareness and alternate the commitment as soon as it is realized that there is a “meaningful risk” (not when “all hope is gone”)

    • Gil Zilberfeld Reply

      Thanks for the comment David!
      Agree with the “over” remark, although the result is the same.
      I don’t like using the term “commitment” because of the side effects that I described. We seem to commit to a date, but not to a quality level, so we help ourselves trample quality. I do think that deciding to go with a story is a decision, that can be changed later. If everyone on the team agrees on the ground rules, understands the terminology, and even more so, the expected behavior (and reality), we’re on a better path to building the bridge between the developers and the business.

      • David V. Corbin Reply

        100% agreement with the quality level decisions [and it must be “appropriate quality” not perfection that is the level].

        There has a recent change from the term “commit” to “forecast”, but I do not like it. Yes, “deciding to go with a story is a decision, that can be changed later”, But, as with any decision, there is a level of “seriousness” about the decision and (hopefully) an understanding of the ramifications of changing.

        If one is not serious about the decision, things easily degrade to the point where rather than decisions (which, as said can be changed) the items are no more than guesses, which can not be counted on in any way shape of form.

  2. Pithythoughts Reply

    “Until we start behaving like doneness matters, the mindset will not change, and worse – behavior won’t change. Deadlines will continue trumping quality.”
    Very well put. It takes consistent discipline to hold the line on quality, teams need lots of support and “top cover” to do this though.

Leave A Reply

Your email address will not be published. Required fields are marked *