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

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

 

About the Author

Vasco Duarte is the host of the Scrum Master Toolbox Podcast and Currently a Managing Partner at Oikosofy. Product Manager, Scrum Master, Project Manager, Director, Agile Coach are only some of the roles that he’s taken in software development organizations.  Vasco was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure.