Agile is a team sport

I am a good team player, but …

If you work in a team, you need to be a team player. Otherwise what is the point of a being in a team?

Having said that, I have worked in two very different types of teams where, I think, being a team player means something different:

• The first team is like a “track and field team”. We are all in the same team but we have our own individual “events” or goals to achieve;
• The second team is was like a “soccer team” where what no player can win an event or a medal as an individual. Here the individual performance of the team members is actually less important than the interaction and alignment of the team.

I am not very sporty but so the sport analogy might not add much more than a general description. However I think the work teams I have been in can be divided into two similar types of team.

It is true that regardless of the type of team, I needed to both get my own work done and participate as a community member in the team, but I also found that:

• I leveraged different strengths to succeed in each type of team; and
• Some things that were a strength in one team were irrelevant or distracting in the other type of team.

Let me try to explain how my way of working, and my definition of high performance , were different in different contexts.

I was an individual contributor

Once upon a time, in a company far far away – I considered myself a pretty good worker because I stormed through work and my clients (internal and external) were very happy with the work I produced.

Part of my job was to:

• Efficiently receive requests;
• Perform a calculation or research some advice; and then
• Communicate the outcome to both experts and lay people.

If you were my manager you could literally measure my output in terms of requests fulfilled and quality of outcome. In fact these things were measured and were helpful in giving me feedback.

Teamwork was also important because I needed to seek help form more experienced people to solve particularly challenging problems, to peer review my work and to help me feel like part of an aligned group of people.

Teamwork was also important because, to be a good team member as I grew more experienced, I was expected to coach more junior staff, help others when things got challenging and contribute to our team “mojo” or culture.

While harder to measure, these things formed a part of my performance feedback and growth. I am still grateful that in my early career I had great managers who could coach me in growing as both individual contributor and good team citizen.

The experience helped me learn to be productive as an individual. In particular it helped me appreciate the need for managing what is now called deep work.

I could not solve complex problems piecemeal while managing too many distractions and emails. At the same time though I could not expect clients to wait while I pondered deeply on some technical aspect of a problem I was solving for someone else.

I learned to create my own flow where I planned shallow work (prioritising, peer reviewing simple things, churning through simple requests) and deep work (deciding if we needed legal advice, complex calculations and considering advice on things that needed serious consideration).

Becoming good at these things, I still believe, helped me to move from competent to high performing and also the set my goals on what represented better performance in the future.

At one point though, I nearly fried myself because the work that needed doing was infinite and I was trusted to get through as much as I was capable of doing.

The problem was that my own definition of high performance meant getting through more work at a higher standard than before.

What made this a problem is that I attempted to get though “as much as I was capable of” purely through commitment, grit and dedication. But constant grit and determination is hard and actually wears you down. Obviously what this means for “high performance” and “good team player” is that you are less capable of delivering the deep work and less available mentally to deal with other people.

So I learned another important element of high performance and team contribution. I learned to set clear constraints on what you and work in away that preserves and rebuilds your energy. I learned this through angst and reflection but I have always included it in my coaching of others.

So I learned to be a better contributor through practice, coaching and reflection. I also learned a lot through post mortems of things that didn’t go well and through what we called “brown bag sessions”, sessions where we shared our challenges and our ideas for innovating in our work.

That was my learning in teams where my own delivery and performance contributed to the team’s wins in way a sprinter wins his or her race and the whole team celebrates.

I suppose some jobs are still like this, where an individual contributor can smash through their own work while helping their peers do the same, but I found that not all teams are like that.

Then the game changed

As I grew more experienced I quickly learned to coach others and to balance keeping my own work under control while also contributing to the success of my team members. This set me up well for every role since and seemed to be ingrained in me from the start.

But it took me a lot longer to realise that in some teams, which I will call agile, my individual productivity was less important than the team cadence and outcomes.

I should have known

I should probably have known this because I had learned team sports many years before I started work.

We played soccer at school, and the coach tried continuously to teach us to pass the ball as soon as we got it and to move to the right position to anticipate where the game would move to.

I imagine he found this quite frustrating because at the start what we all wanted to focus on was dribbling the ball and running past people, or scoring a goal or tackling another kid. While we did practice these individual ball skills, it was not the focus of the coaching that I remember.

Over time, we learned that the coach had a point. The team that played better as a team always seemed to win.

Of course I never had Pele or Maradona in my team, but even at an elite level I assume that the best players have extraordinary situational awareness and strategic thinking beyond their extraordinary ball skills.

But I had forgotten the lesson

But that was in junior school sport. I didn’t really connect the lesson to work until later in my career.

When I joined an infrastructure team, I was a data guy and a Unix administrator. Managing data is like solving a puzzle, so it can look like an individual thing and Unix is a really stable thing to manage if you follow the basic rules. It seemed as though if I managed my patch well, then I was contributing to the team effectively.

I was certainly able to look good by converting data and passing it on and by being lucky enough to manage stable infrastructure when others had to manage something far less so.

What I missed though is that you cannot win if part of the infrastructure is stable or part of the data has good integrity. With infrastructure, you can only win when the whole team wins.

I was the primary contact for the specialist testing team and I supplied them with refreshed data. I was seen as responsive and I remained efficient because I forced them to define what they needed so I could give them a clean data run each time.

But then crisis hit the testing team – there were substantial changes to the architecture and the features of our integrated set of applications that nobody thought to tell the test team. I still don’t know how that happened, but they came to me apologetically and said they needed a complete rebuild of their data.

I jumped in to help and I learned to my surprise that I didn’t know how they used the data.

I anticipated that the data was needed in a different configuration and that we needed to integrate it into their automated scripts. But when I sat down late at night and paired with a tester, they saw me run my own script to define the data fields and they realised that they could use my script to reset the system and run some automated testing and then simplify their work massively. I had just never realised that they were doing a chunk of work on the same things I was doing.

We still needed to do some work but the work we did was different and I almost stopped getting any data requests because they could use a basic script that we co-created. It made my life really easy and they said I was a hero. But in fact I was just in the right place when somebody else saw how I worked for the first time.

A similar thing happened when we had to fix some recurring incidents that were not the fault of the unix system, as I was able to quickly prove. But after proving the problem rested elsewhere the Windows (NT) crew showed me a theory about why their system was falling over. I realised that I could see a predictor in my data logs that signaled this was happening because ironically the Unix system became less stressed before their system had an issue. So we worked together to build a joint logging system and we became far more responsive. Again, my contribution was less about being good at Unix and more about being in the right place at the right time.

But being in the right place when the ball arrives in soccer is not luck, it is about situational awareness and the ability to anticipate the way the game will flow. Had I been better at this we would have won our victories sooner. That, to me, would have made me both a higher performer and a better team player than before.

The same happens in many tightly knit technical teams. Good situational awareness beyond your own task and beyond your role is where a lot of the value comes from being in an interdependent team.

Having seen this in one context, I saw it very plainly when I worked with web development teams and content teams.

You may not believe these rules are true but I found that front end developers always finished their work before back end developers. They would then create things like “stubs” that allowed them to keep moving forward without waiting for the backend and then found surprising integration errors which led to a lot of work. It was kind of like young kids rushing forward on the soccer field, hoping someone can kick the ball to them, when the defenders are being over-run by the other team.

The same happened with content, where people constantly reviewed other people’s work without knowing the goal or message of the content. They would also rush out beautiful but inconsistent messages that detracted from the overall value of the content, as well as creating a terrible information architecture.

The web teams fixed this problem by “turning agile” or, more specifically, learning to play as a team. I was there for the journey and learned a huge amount as I saw different players in the team sacrifice their own local efficiency to focus on keeping the whole team moving.

This was made possible because we made the work transparent and because we built formal interaction into our work. But it was also made possible because the high-performers in the team played as a team rather than as great individuals.

Our definition of high performance had shifted and so has our expectation of being a good team player.

A similar thing happened with the content team, though it was more to do with a team member who because the “editor” and coached people to write consistent content and to understand the value of information architecture.

Again though, the expectation of the content team had shifted from “just” interacting with stakeholder and writing good content” to working as a combined team. The editor championed teamwork over individual accomplishment.

Where people had been reacting to unanticipated demands and doing unwanted rework, they were now actively anticipating and supporting what others were doing.

So I started to realise that it mattered where I positioned myself on the metaphorical field and how I received and passed on work. It mattered how we gelled as a team and I needed a lot more situational awareness.

I think this is where I learned what an agile team really is, before I found out about jargon like story walls and sprints.

Implications

I don’t think that this is an example of an old way of working and a new one. I think it is a case of understanding the context in which the team exists:

• Context A is where “individual contributors” excel at what they do and their work delivers value on its own. It is like an athletics team running individual heats, each of which adds to the score; and
• Context B is where “team contributors” play the same game as a team. The way they pass the ball among themselves and position themselves to anticipate the flow of the game is more important (I believe) than their individual ball skills or excellence at completing their individual tasks.

Keys to high performance

I said earlier that I thought I needed to leverage different strengths when in different teams and, while I am not sure I have captured everything, I will share what I think an initial list looks like. These are the strengths that, I believe, lead to high performance for the individual in different contexts.

Individual contributors need to be able to:

• Run their own race without being too dependent on others
• Complete work at a good pace to a good standard
• Identify exceptions where help or further support is needed
• Prioritise and chunk work effectively
• Learn not to burn out

Team contributors need to be able to:

• Find their role in the team and the gap they fill in that team
• Maintain situational awareness – Know where others are in the team are at and where the pressure is on across the team
• Know where the goal is and how to move the “ball” toward the goal as a team, rather than just focusing on their own skill with the “ball”
• Receive work, pair on work and pass work on really effectively
• Leverage and support the strength of the team

Impact on retrospectives

In context A, a retrospective can be a sharing of tips and discussion of what has gone well or been challenging for the individuals. Each person wants to know how they can improve their own productivity, use tools better, find easier ways to tackle new challenges.

When I was in a team executing work against a relentless steam of customer requests and new problems, this is how we reflected and learned as a team.

But in context B, this is not how a team reflects on how they went last game and how they can improve for the next game.

Just as a soccer team would look at the score (did we score more goals than the other team) and then reflect on what led to the scores and the misses, an integrated work team will look at whether they hit their goals as a team and what led to that result.

Both the soccer team and the agile team will look at the way they passed the ball, the way they set up the goals and the way they took advantage of the opportunities that presented themselves.

For the team working in context B, this means that retrospectives are not a series of ideas from individuals about what worked well from their perspective and what challenges they faced in doing their own work.

These things matter, but the main game is to look at the team goal and whether it was achieved, and therefore to look at which stories were completed successfully and which were either not finished or not done well.

So the retrospective will look far more at how the team scored or fell short of their goals, with less concern for whether individuals got through the work they were assigned.

Is agile better then?

I think it is tempting to assume that interdependent teams with shared goals are better than teams where individuals run their own races. A lot of management books emphasise the power of the team and the importance of shared victory.

I think all teams want to win. But I think it is better to understand the context in which the team wants to win and optimise for that. An athletics coach would not try to make everyone in the team run the same 100m race and a soccer coach would not tolerate individual glory hunters.

This leads to a common impediment to agile fluency:

• Most agile practices, I believe, are designed to support the interdependent team that has a shared goal, like a soccer team.
• Many people are used to being evaluated on their individual delivery. Logically then, they try to maximise their individual delivery, without developing the situational awareness to understand how the team is going or where they need to move to in order to support others.

You will see this conflict when developers start work on a new story while waiting for their previous one to be reviewed and tested. You will also see it when senior team members leave work sitting untested while they complete more stories, leaving a list of stories waiting for someone to be free.

You might also see it when a scrum master tries to force the whole team to discuss every task when actually only one person is involved in each task.

You will also see it in the team retrospective.

• This is particularly common when the team is in context B but does not realise it. As a result the team does not discuss what contributed to their team goal or hindered their ability to flow as a team. Instead they will discuss what went well and badly as individual observations, leading to superficial discussions.
• Less so you might see it in context A, where the team have a retrospective don’t need to optimise their interaction. They could instead be sharing lessons and challenges that each person had and giving advice, or they could be replacing the team retrospective with cross team coaching and mentoring.

I hope that makes sense. What it means to me is that the team needs to know what game it is playing and how to optimise for that game.

In particular that means their retrospectives will be based on how to win the game (or complete the mission) rather than as a thing done because Scrum says to do it.

Let me know if this is a useful insight or an academic discussion.