You're Doing It Wrong: Deadlines
You're Doing It Wrong: Deadlines
Often times Scrum teams work on a project in order to fit it into a certain time window. But, to truly practice Scrum, a product needs to match the Definition of Done.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
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.
We discover new stuff, hidden details. We also find out unplanned tasks crept 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 the trunk and hope that testing can occur before 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).
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 the end of a 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 do the best we can 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 is, 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 teams' 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.
Published at DZone with permission of Gil Zilberfeld , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.