The Cone of Self-Organization

Good day, good people!

Today, let's talk about #strategy, #product_goal, #sprint_goal, and #self-organization.

At first glance, I'm mixing different concepts in one sentence, but I believe they're all connected. How does it work? Follow along!

Strategy

Strategy, as described by product strategy expert Nikita Filippov, is a set of actions taken by the product leader, not an artifact. When the strategy is present and regularly communicated to all employees, it clearly defines what we DON'T do. This creates what's known as a "corridor of freedom" (pink area on the diagram) - a long-term area where your Product Owners or Product Managers can self-organize with their teams to define their product goals. The task of top managers and owners at this meta-level is to constantly convey and empirically change the following message: "based on current knowledge and experience, we believe our shared business success is buried somewhere in this area."

In the absence of this sense and/or transparency within the company, the following circus ensues:

• we launch new products on the hype wave (hello, chatGPT features)
• we're constantly falling behind
• we need to hire more and more people

Product Goal

The latest edition of the Scrum Guide introduces a "commitment" for the Product Backlog called the Product Goal (green area on the diagram). It's simply a description of our product's future. If the Product Goal is present, then Scrum Teams (if you're using True Scrum) can self-organize to determine which functionality to include or exclude from our product. A working Product Goal also allows us to say "No" to all stakeholders around us with justification. The task of Product Owners or Product Managers at this level is to constantly say "No, because it doesn't align with our current Product Goal, which is aligned with our Strategy."

In the absence of this sense and/or transparency at the product level, the following circus ensues:

• everyone with power in the company tries to manage the product features
• more features, more problems
• more teams for more features
• no Sprint Goals
• instead of Apple-like minimalism, the product looks more like a pinball machine.
  

Sprint Goal

The Sprint Goal (purple on the diagram) is a well-established entity in Scrum, and in the latest edition of the Guide, it has officially become known as the Sprint Backlog Commitment. It represents the hypothesis for the next Sprint, which the Scrum Team launches as a mini-project to validate the reality that this hypothesis brings us closer to the Product Goal through the resulting Increment. This entity allows the Scrum Team to flexibly manage the Sprint scope (including removing or adding Product Backlog Items) and self-organize on a daily basis to achieve the Sprint Goal in the most elegant and impressive way with minimal effort. And in the next Sprint, the Scrum Team can redefine a new self-organization corridor in the form of a new Sprint Goal.

Without this sense and/or transparency at the iteration level, the following circus begins:

• Let's cram even more tasks into the Sprint so that all team members are utilized 100%.
• I'm a backend developer, I won't touch the frontend - give me more backend tasks.
• We don't understand why we should work as a team.
• The Sprint Review turns into a Sprint Demo without an Increment, where we simply report to stakeholders and promise to deliver features that are nailed to the quarterly roadmap.

Strategy→Product Goal→Sprint Goal

Now let's look at all three entities together. What do we see? We see the cone of self-organization, where at each of the three levels, there is an opportunity for continuous empirical work. But remove just one level, and everything will get mired in chaos. And now look at your company through the prism of this cone and honestly answer - is Scrum not working, or did someone at the top do a poor job?