Why I was wrong about Scrum + “Hard Goals”

I am so happy to admit to you that I made a mistake.

I thought reaching the goal was the most important thing. “Isn’t that what Scrum is all about?” (I thought). I used to value making sure my team’s completed point values looked good at the end of the sprint. I thought pushing them to produce work would be more helpful so they learned how to commit to a goal. But sometimes that attitude of mine simply encouraged the developers to produce code that either they weren’t personally proud of or that I sure as heck wasn’t happy with when it came to the code review. So what was the value of making it to the goal line if the ball is busted and deflated when it whizzes past?

Keep reading to learn why admitting your mistakes in not only ”okay” but also possibly the most productive thing you can do.

I recognize my misunderstanding of Scrum’s goals when the Scrum Alliance announced changes that were made to the Scrum guidelines:

“As of 2011 the Development Team no longer commits to the work planned in the Sprint. Instead, the team creates a forecast.

This is a major change.

A commitment implies that there will be no new insights during the Sprint. A forecast is taking into account empiricism: transparency, inspection, adaptation.”

That last line really excited me, so let’s break it down. I’m hoping that by putting less emphasis on committing to deadlines I’ll be giving my team the opportunity to take the time to embody the values that Agile really emphasis:

• Transparency: It would be so amazing for me (as the frequent Scrum Master of the team) if I didn’t have to consistently coach/bother the team to communicate early and often about difficulties. Are my teammates keeping quiet because they’re afraid I’ll find out that they’re maybe going to miss the “commitment?” I certainly hope that’s not the case, but it’s possible that they’re afflicted by the same procrastination issues I also have had to deal with. And as I’ve described before, the best cure for procrastination is to remove the fear that is preventing progress— so commitments are out for me. So maybe the simple language tweak of using “forecasting” will help my team to communicate sooner if a particular user story looks like it’s going to take more time than we originally predicted. This way the blame is focused less on the developer’s tech skills and more on the scientifically proven difficulty that all humans have with accurately estimating time.

• Adaptation: I would be unbelievably happy if I watched one of my teammates ask the team if we can pivot and rearrange the user stories we brought into the sprint. This could easily be needed if we have surprising learnings that tell us our plan will need to adapt to reality. I have always told my teams that negotiating before a sprint is kicked off is better, but that we can still talk about necessary changes inside of the sprint… but I guess that the big bad commitment was preventing them from bringing up any changes. That’s no good. I need to foster an environment where any topic (especially necessary changes) can be brought up. After all, accepting change (ie acknowledging impermanence) is a core aspect of Buddhism, and I have to say it’s made my life so much nicer… so why would I want to deny my team the peace that comes from knowing that change is okay and is to be expected. Hey, I don’t have to throw away all that Scrum used to be— I can always tell a teammate that the change in scope can be represented as new work in the next sprint if the change is more of an enhancement than a misunderstanding of the original acceptance criteria. We can slice and dice the work however we want. We can do whatever works best for the team… so long as the team is comfortable to bring it up.

• Empiricism: Not knowing is core to one of my great loves, the scientific method. TheHappyScientist.com describes the scientific method best when they write: “A theory starts as one or more hypotheses, untested ideas about why something happens. […] To become a scientific theory, an idea must be thoroughly tested, and must be an accurate and predictive description of the natural world. […] theories change frequently as new evidence is discovered.” Empiricism is also core to Buddhism (which is the through-line of most of my articles on CubicleBuddha.com). I wish that everyone can know the peace and calm that comes from accepting that it’s okay to not know the answer. You can’t learn unless you admit that you don’t know. That’s why I’m always trying at least two or three solutions when I’m trying out a new language or technology. For instance, I recently decided to challenge my tendency towards functional programming. So I made a hypothesis that a reduce function is better for aggregating data but then after I had to hand-roll a groupBy-style hashmap (because my lambda function didn’t have lodash) I determined that a foreach was the most readable solution. How amazing? By challenging my own preconceived notions, I now have multiple theories on aggregating data and I have a more refined knowledge of what constitutes readable code.

Why Empiricism Is More Important Than Scrum Points

I want my team to also have the time and freedom to question their own code. If they do, then ultimately we will have a better product, more confident developers, and happier customers. Oh, and I won’t have to cringe when a code review request is sent to me and the submission looks like the developer threw the code together quickly. Take the time to enjoy your craft!

What have you been wrong about that brought you happiness?

Recognizing my misunderstanding led to greater happiness for my team and for myself. So what are some notions that you've had that you were amazed when they flipped?