The Biggest Problem I see Agile teams face and the solution that works for me

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

This game is a mess šŸ™

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! ?

3 thoughts on “The Biggest Problem I see Agile teams face and the solution that works for me

  1. 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.

      • 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.Ā Ā»?

Comments are closed.