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.

Surprise!

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.