Scrum and OKRs don't compete. They do fail for the same reason

The question of whether to choose one or the other is badly framed, and the episode deals with it in the first part. These two things work on different floors. Scrum organises the creation of value inside a team. Working with goals implements strategy at the level of the whole organisation: it takes a direction set out over two, three, sometimes five years and translates it into a year and a quarter, and the right question in a window of three or four months is what the best thing is that we can do now to get closer to a goal two years away. Agility in itself is not one of these tools, by the way. It is a mindset described by four values and twelve principles, embodied in an endless number of practices, and Scrum is only one such set. What they share is a rhythm, and not by chance: iteration, a review of what has been produced, a retrospective of how we worked together.

More interesting is what they have in common on the side of failure. An implementation that starts with processes and practices, counting on the mindset growing somewhere along the way, is a road of suffering. That line comes up in the episode about Scrum, but straight afterwards it turns out to describe our own backyard as well. Most texts claiming that Scrum doesn't work or that agility is over have exactly this common denominator. It is identical with goals: saying that OKRs don't work usually means the problem lies somewhere else entirely, and the method is a convenient scapegoat. That is why, when we come into an organisation, we often start with something other than goals. The most common form of breakdown looks the same in both worlds: the framework is stripped of its pillars and values while the rituals remain, so the calendar is full of meetings that lead to nothing. The second shared problem is how the result is counted. An outcome measured by effort, meaning how much I did and how fast, versus the question of what will change once I have done it. Both stem from being used to project work and to thinking in initiatives.

Finally, there is a condition without which neither of the two will work, and here the episode is merciless. Without a culture that respects autonomy and drawing conclusions from data, nobody will take responsibility for either a goal or an experiment. With a leader who points a finger at what to do, and with costly mistakes, there is no room for testing hypotheses, because everyone is afraid of getting it wrong. In a tightly managed organisation without autonomous teams, performance management or classic project management will work better, and there is no point forcing a round peg into a square hole. Along the way, a popular objection is defused: that cross-departmental objective teams won't have time to form because they are set up for a quarter. It only holds in one arrangement: when the board sets the goals itself and hands them out, picking different people for each, for example two objectives with eight key results and a different group every time. Then everything really is built from scratch each cycle. When the strategy and goals are worked out by the same permanent group of leaders together with the board, the context simply doesn't disappear between cycles. That leaves us one thing to improve in our own work: in retrospectives we mainly ask about what didn't go well. We all know what isn't working for us, and the worst thing is not knowing why we win.