Teams playing basketball
Photo by Max Winkler on Unsplash

Two kinds of teams, who couldn’t be working more differently. They differ in their structure, how they work together, and how they communicate and share information. I do think that only one strives in an Agile environment and that organisations who want to hold on to the other will face difficulties. Here’s a description of these two kinds of teams.

I call the first team a rockstar support band. At its core, this team has a rockstar developer supported by the rest of the team. The rockstar developer is like a surgeon in an operating theatre. There is an anesthesiologist taking care of the patient’s consciousness level on behalf of the surgeon; a scrub tech passing instruments to the surgeon; a circulating tech tying the surgeon’s surgical gowns; a nurse assisting the surgeon; students doing minor tasks for the surgeon. Similarly, the rock star developer is supported by a database developer taking care of data on behalf of the rockstar developer. A frontend developer implementing the frontend according to the rockstar developer’s vision. A backend developer who takes care of the backend for the rockstar developer. A UI/UX developer, taking care of… you get the point.

Like the surgeon, the rockstar developer is seen as the leader of the team. Whenever there are interruptions, the supporting team members make sure that the rockstar developer won’t get disturbed when she’s coding on the important stuff. The rockstar developer always tries to code on the most important stuff. The team takes care of everything else, so the people can enjoy the sport and even gamble on them using sites as w88 which are amazing for this.

A rockstar support band is like Real Madrid and their top player Christiano Ronaldo. Or FC Barcelona and their top player Lionel Messi. The teams are built around their top player, like a team in an operating theatre is build around a surgeon. With Ronaldo and Messi, this makes sense. They have developed extraordinary soccer playing skill. Both teams’ strategies are often to get the ball to the top player in the hope that he will do some genius tricks to score a goal. The US coined a term for these kinds of players: franchise players. “…a franchise player is an athlete who is not simply the best player on their team, but one that the team can build their “franchise” around for the foreseeable future.

This kind of teams has been proposed before. Robert C. Martin called them Master Craftsman Teams” in 2009: “At the center of this team is a master programmer. This is someone who has been programming for two decades or more. This person understands systems at a gut level, and can quickly make technical judgements without agonizing over them. […] Our master has three lieutenant journeymen who themselves each have three apprentices. Our journeymen have at least five years of experience, and are capable both of taking and giving direction. They can make short term tactical decisions, and direct their apprentices accordingly. At the same time they take technical and architectural direction from the master. […] Now imagine a team of 13. One master, three journeymen, and nine apprentices. This is a powerful unit.

The Mythical Man-Month by Frederick P. Brooks

But we can go back way further than that. Over 40 years ago, 1975, Frederick P. Brooks Jr. wrote the book The Mythical Man-Month. It’s a collection of essays, one of which is the groundbreaking “The Mythical Man-Month“. From this essay we still enjoy pearls like this: “Adding manpower to a late software project, makes it later.” However, in another essay in this book, called “The Surgical Team“, Brooks proposed a team structure with a strict hierarchy. At the top of the teams’ hierarchy is a single person, called the surgeon. Nine other people support the surgeon. There is a co-pilot, a programming clerk, a toolsmith, a tester, a language lawyer, an administrator, and an editor, with secretaries for the two last roles. One of the benefits listed by Brooks is this: “Second, in the conventional team the partners are equal, and the inevitable differences of judgment must be talked out or compromised. […] In the surgical team, there are no differences of interest, and differences of judgment are settled by the surgeon unilaterally.” Sounds a lot like the arrogant Marvel’s Doctor Stephen Strange to me, before he became the Sorcerer Supreme.

The second team is what I call a two-steps-then-passing team. This team has lots of skilled individuals. But not a single player on that team has the skills of a Ronaldo or Messi. This team is a rockstar support band without a rockstar. But what the team is exceptional at is passing the ball. One example in soccer would be Argentina in the World Cup 2006. This soccer team passed 26 times before they scored a goal against Serbia & Montenegro:

Another example, this time in basketball, is that of the San Antonio Spurs. The media describe the Spurs’ game as “The Beautiful Game“. The San Antonio Spurs’ Beautiful Game is not about the individual hero. Every player is constantly sacrificing his own chances of scoring by passing the ball to their team mates which is the goal of every game, and that’s why there are so many fans of these sport, with people even gambling on them in sites like online.

The 7 Habits of Highly Effective People by Stephen R. Covey

There are also two-steps-then-passing product development teams. These teams focus on passing, not on scoring. Once they master the passing, the scoring will almost take care of itself. Developers in these teams are swarming. They look out for and often communicate with each other. These teams are proactive. Stephen Covey calls habit one in his outstanding book The 7 Habits of Highly Effective People “Be proactive“. It means being responsible as in being able to respond. “It’s not what happens to us, but our response to what happens to us that hurts us.” It means taking initiative. Two-steps-then-passing teams focus on their circle of influence. And more than just focussing on this circle, but aiming to expand it.

In his 2016 article in The New York Times, called What Google Learned From Its Quest to Build the Perfect Team, Charles Duhigg wrote about a study conducted at Google. The researchers wanted to find out what makes an outstanding team. They observed hundreds of teams and found two ingredients that are vital for good teams. Ingredient number one was social sensitivity, i.e. how well one understands the mood of someone else based on their tone of voice, their facial expressions, etc.

The other one was even airtime amongst team members. Duhigg wrote: “On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment. But in each case, by the end of the day, everyone had spoken roughly the same amount. ‘’As long as everyone got a chance to talk, the team did well,’ [researcher] Woolley said. ‘But if only one person or a small group spoke all the time, the collective intelligence declined.’

In rockstar support bands, the rockstar has the most airtime, followed by his closest peers. People on the sideline were generally quieter, and when they said something, they looked for approval by the rockstar. With two-steps-then-passing teams, airtime was evenly distributed. They focus more on listening than on speaking and on being genuinely interested in what others have to say. They often encourage others within the team to talk before they took the proverbial microphone.

There is also a difference as to how these two kinds of teams get work done together. Rockstar support band tend to cooperate. Two-steps-then-passing teams collaborate with each other. There is an important difference between cooperation and collaboration. When teams cooperate, they divide labour at the beginning of a work period (say, a week or so). Then the individuals work on their parts for the rest of the work period. At the end of the work period, the team members integrate their finished workpieces.

Compare that to how teams collaborate. At the beginning of a work period, the teams create a plan about how they are going to work together. Then they actually work together. Throughout the work period, they share information about the current workpieces together. The frequency depends on how much and how often things change during their work, or how often new information would help team members do a better job. Whenever a piece of useful information occurs, they share it. I’ve seen teams doing stand-ups every 90 minutes. I’ve heard of another team doing catching up every 25 minutes, i.e. one pomodoro. They write that, because of this approach, “…everyone is across everything going on in the team and everyone can provide input on whatever is being worked on. Our solutions tend to be very well thought through.” There are more benefits: “We tend to waste less time on implementing something that will not work or is suboptimal. On quite a few occasions a pair worked on something for one pomodoro, then discussed it with the team only to realise that what they are doing will not work. That is at most 25 minutes wasted, without pomodoro that could have been a whole morning wasted.” Whenever there is progress done with any tiny piece of work, it will be integrated immediately with the whole of the work done so far. The team takes care of any problem during that integration immediately. This way, big problems don’t pile up. There won’t be a big bang integration at the end of the work period, as it’s often the case when you cooperate.

There is also a difference with the intention of the communication between these two kinds of teams. The members of a rockstar support band share information if they want others to action. For example, a team member might be stuck and asks for help or input. Or a team member is done with a piece of work and wants a colleague to continue working on it.

Rockstar support bands are otherwise relatively quiet. Rockstar support band members don’t want to interrupt others with information and they don’t want to be interrupted with what they see as useless information as well. I once coached a team where a team member described it to me like this: “When I work, then I want everyone to respect my walls.” He pantomimed walls all around his desk and chair. “Don’t talk to me if it’s not absolutely necessary. I don’t want to be interrupted. I highly value flow and if you take me out of my flow, I won’t get anything done. So, leave me alone!

Members of a two-steps-then-passing team share information about what they did and learned, very often. Regardless, whether they need others to action or not. They either do that after a certain amount of time or after they completed a bit of work. They ask themselves for each bit of information: “Would that be of interest to my colleagues?” If in doubt, they share. Also, team members give each other feedback about what was a piece of useful information. It’s a self-regulating system.

Two-steps-then-passing teams don’t want to be interrupted all the time either. They use asynchronous communication tools, such as Slack, Google Hangouts, Microsoft Teams, and so on. I call this communication style slow communication. Not because the information travels so slow—it does the opposite!. I call it slow communication because it takes out the stress and haste with which team members communicate with each other. Each team member can decide for themselves when they want to go through the messages from their peers. They decide, when they want to interrupt themselves with team information. They manage their own flow.

Rockstar support band members are usually skeptical of sharing information. They don’t share information as freely as two-steps-then-passing teams do. They are afraid of drowning in information. And they don’t see the benefit. Why would you share that information when you don’t expect others to action upon it in the first place? Because each team member might benefit from whatever other team member discover through their work. If my colleague over there learned something about the product we are working on together, then that might be of potential value to me, too. My own decisions might be affected by that. How do we find out whether it is of actual value to me? By sharing information. That way, two-steps-then-passing teams progress way quicker than rockstar support bands.

And all this sharing information about work done helps to get a sense of progress. When I see, on a regular level, what others have done and learned, I get an impression of how all the work progresses over time. In their HBR article The Power of Small Wins, Teresa Amabile and Steven J. Kramer describe what they call the progress principle: “Of all the things that can boost emotions, motivation, and perceptions during a workday, the single most important is making progress in meaningful work.” They further explain that “[p]eople are most satisfied with their jobs (and therefore most motivated) when those jobs give them the opportunity to experience achievement.

As an Agile coach, I very often come across the rockstar support bands. Teams try to improve their work, guided by the Agile values and principles. They often are rockstar support bands. Then they adopt more and more the behaviour and characteristics of two-steps-then-passing teams. I have experienced being a member of both kinds of teams. I have also experienced being a member of teams turning into two-steps-then-passing teams over time. If you are intrigued by the two-steps-then-passing teams, I can highly recommend looking into it.


Source link

Leave a Reply

Your email address will not be published. Required fields are marked *