Skip to main content

“I Don’t Care About Scrum, I Do Care About Empiricism”

September 1, 2023

Banner

Confession: I don’t care about Scrum… I don’t even care about the Scrum Master, Product Owner, and Scrum Teams. I don’t care about the Scrum events or the various artifacts. 😲

As a result, I rarely engage in online discussions about the Scrum framework. Debates focused on responsibilities, rules, timeboxes, and other details. Sure, they have their value, but most discussions are only focused on theory and how to interpret the Scrum Guide. And often the tone is “my interpretation is correct, you are wrong”. Or: “it’s true because it’s in the Scrum Guide!”

Boring, meaningless, and often missing the point… 🙄

✅ I do care about empiricism!
✅ I care about transparency, inspection, and adaptation, and how this is required for empiricism
✅ I care about self-organizing/managing teams
✅ I care about building trust and psychological safety
✅ I care about driving change from the inside out
✅ I care about supporting teams to navigate the complexity
✅ I care about effective collaboration with stakeholders
✅ I care about shared product ownership
✅ I care about using empiricism to minimize risk, increase predictability, and deliver value sooner
✅ I care about how in complex work, goals give teams guidance and focus
✅ I care about values like openness, courage, focus, commitment, and respect

It’s all part of the Scrum framework, but at the same time, it’s not about Scrum at all. We tried to capture the essence of Scrum in the illustration below. The most important isn’t the part in the middle, which mostly focuses on the mechanics of the Scrum framework. In our experience, the essence is…

In complex work, more is unknown than known;

The unknown is discovered by releasing done increments early and often;

With these increments we validate assumptions;

We learn what is needed and avoid the risk of spending time and money on the wrong things;

As a result, we can deliver more value to our stakeholders sooner.

Poster

Scrum can only work if it's supported by the right mindset and behavior. Therefore, Scrum offers five values that can be used as guiding values. As we describe in the whitepaper I wrote together with Johannes Schartau and Christiaan Verwijs, teams can use these values as an instrument for reflection and decision-making. In addition, the values also support teams to live up to the commitments towards the Product Goal, Sprint Goal, and the Definition of Done:

  • Openness: Be open about how things are going. What is going well? What is not? Where do we see an opportunity to expand our Definition of Done? Where are the challenges and opportunities?
  • Courage: Be courageous to do the right thing. Say “No” to things that impede the empirical process. Show courage by working on tough challenges together. Ask for, and give feedback about things you are not sure about. Ask questions and admit what you don’t know or are uncertain about;
  • Focus: Keep the focus on the Product- and Sprint Goals and the goals of the Scrum team. Create a space where people can keep and sustain focus;
  • Respect: Respect the skills, expertise, and intelligence of the members of the Scrum team. Trust their ability to self-organize around complex problems. And respect the uncertainty that is inherent to complex work;
  • Commitment: Create an environment where people can personally commit to working together as a team towards the Product- and Sprint Goal, using the Definition of Done as a reference for the quality everyone can expect from the team.

Once teams, management, and stakeholders understand how Scrum is a framework to minimize risk, increase predictability, and deliver value sooner, the focus hopefully shifts from the mechanics of the framework toward the truly important enablers. These are the three pillars of Scrum: transparency, inspection, and adaptation. It’s these three pillars that allow empirical process control, and it's the values and commitments of the Scrum framework that bind it all together and make the framework actually work. So why don’t we focus a bit more on those and less on the mechanics of Scrum?

If you’re interested in learning more, join my public PSM II class in Amsterdam, or send me a message to discuss in-company possibilities.


What did you think about this post?