This is a #SkiTertulia blog post. If you want to know more about #SkiTertulia, visit the announcement page.

When I work with teams from all over the world (multiple different national cultures, multi-national, distributed or co-located), the biggest problem I see those teams struggle with is very simple. They arenāt teams.
Let me use an analogy. Imagine you are part of a team that plays basketball. You get to the court and notice that everyone else is using a random uniform. Thereās no way to tell who is on your team.
Now, further imagine that you know, for sure, that you are on the court, but you donāt see any lines on the ground. The court has no boundaries (you will be told when you are off-bounds, someone shares. By being zapped with a reprimand from a ābossā?).
When you ask āhow should we keep score? I donāt see the hoops anywhere!ā, they tell you: you will know when you are winning. (After which I would ask: How? Divine inspiration?)
Finally, the referee isnāt there and wonāt show up. Yet, you are told, you must win the game. The 5-year plan (read āroadmap completion on timeā) depends on it.
I know. This is tongue in cheek, but now letās see where the analogies are between this metaphorical mess and the real mess, real teams are facing today.
You donāt know whoās on the team
Letās say that your organization has multiple products and/or projects to work on. The usual setup is that people with certain skills (mostly everybody) has to work on N of those products, where N is usually far greater than 2.
What this leads to is that, when you need help and ask a colleague for help, she will tell you: āSorry, Iām working on that other product/projectā. Boom! Now you canāt even be sure that your āteammatesā will be there for you when you need them. Pretty much equivalent to the random uniform problem in a basketball court.
The boundaries are arbitrary and decided by āthe bossā
The court not having the boundaries drawn on the ground may seem like a far-fetched situation that would not be happening in our places of work. However, many of you have told me that you donāt always know what goals you are reaching for (more on that later) and also priorities are changing constantly and unpredictably. Even within 2-week periods (the Scrum iteration).
But there are other boundaries that are changing. For example, middle-management infighting usually leads to certain resources (and I do mean resources, like machines, servers, etc.) and certain rules changing over the time of the project. These situations are usually called āconflictsā. Conflicts happen also because the rules arenāt clear from the start.
No one is keeping score, and āwinningā is not defined
Finally, the problem I usually start talking about immediately when I meet a client is: the definition of the goal. Or, in other words: how do know we are winning?
Iāve worked in organizations that try to solve this problem by stating the goal is to āimplement all the features on timeā. The problem is that completing something on time is not enough to be rewarded in the market. The market, famously, rewards only some features, and it may reward those massively! The easiest example for me to use here is the Android/Apple vs. Nokia debacle of the early 2010s.
Nokia had A LOT MORE functionality than any other competing platform. But it did not have the RIGHT functionality. The market changed. And hereās the kicker: people at Nokia thought they were winning the game, even when they were losing by 50 points!
Knowing how to, and actually keeping score is critical for the success of your teams.
My solution to this real (and metaphorical) mess
Over time, Iāve tried many different approaches to this mess. But the one that I use now, and have had success with is rather simple.
When I start an engagement I work with the client to define āone team with one goalā. This OTOG (One Team, One Goal) approach is not very complicated (even if putting it in practice may be), it basically states: every one that is working on the team must have the same goal, and it must always be possible for anyone to know who is on the team.
Iāll share some stories about this in later posts. But if you want to know more about this approach as well as all the other breakthroughs weāve had over the years, why donāt you join Jacopo Romei and me in our #SkiTertulia in the Alps? You risk being inspired! ?
Thank you for this inspiring write up. It states some of the issues I have been facing as a young Scrum Master. I am greatly inspired by this. The solutions are very practical and easy to understand.
I’m happy to read that Dalida! Don’t forget to share your story, and what you’ve learned. And when you are ready maybe you can be a guest on the https://scrum-master-toolbox.org/ ? š
Thanks Vasco. I am definitely sharing my story with everyone especially young scrum masters . I always keep in mind that « sharing is caring, Vasco D. »?