Short Article

Otte, Kondradt and Oldeweme from Kiel University in Germany have produced some interesting research on team reflection. Reflection being where a team looks back on past experiences. Their most research publication concludes (amongst other conclusions) that the quality of the reflection has a stronger impact on team performance than the quantity of reflection. What does this mean? Do we cancel every second retrospective?

The researchers studied teams using a simulation that ran two waves with five minutes of reflection between waves. All teams had the same amount time for reflection but could choose to use all of this time or not. Team performance was measured in both waves of the simulation. Reflection quality, quantity and implementation of changes was measured by the team member’s filling in a survey.

What are quality and quantity in this study? According to Otte et al. a high quality reflection is one where team members seek and evaluate detailed information on performance. This approach to quality may include going into detail to find the root cause of their problems or being detailed in the assessment of quality. For the authors of the study quality is about detail, going beyond the superficial. What does quantity mean in this study? Rather than how long the teams spent on reflection quantity in this study is how often information is sought and evaluated. Rather than going into detail on root cause (quality), quantity is regularly going identifying root causes. So a team can have both quantity and quality of reflection.

So the conclusion that quality is more important to team performance than quantity is not about the time spent on reflection. It is about the nature of the reflection. Lots of superficial measures do not help a team improve as much as fewer measures that are more detailed.

Another interesting, but not surprising, finding is that teams that implement changes to their work practices that come from reflection improve their performance more than just having quality reflection. Having a good look at how the team is going is great, doing something about it is even better.

In the previous post we wrote about how a team’s working methods tend to get set implicitly at the start of a  project. Connie Gersick found something else about how teams tend to work across their lifespan, though.

When the project is around its halfway point, teams are likely to re-evaluate their working methods in an effort to achieve their goals in the time remaining. This is more likely if they are receiving information from outside the team, especially around how they are performing. They learn from the first half of the project, and will talk explicitly about how to approach the work.  Gersick found that teams that are performing well can just check in and keep doing what they are doing.  Teams that were not performing well may have a meeting around the halfway mark, review how they are going and persist with their less than optimal approaches to work: positive changes are possible, but they are not guaranteed to just happen naturally.

This time is an excellent opportunity to learn and shift behaviour.  There can be a naturally occurring reflection process that happens around the halfway point to a deadline, so use that opportunity to make some positive changes. Teams may change their work practices for the second half of their project in an attempt to meet the deadline.

How to use your team’s midlife crisis as an opportunity

First of all, be aware where the halfway point of the project is, and use the opportunity. You might call a halftime review meeting. Frame the meeting as such – you’re halfway through, it’s a time to think about what you’ve done, what has and hasn’t worked, and using that knowledge to make conscious decisions about how you will approach work in the second half.

Second, break up projects into smaller, discrete units, with shorter timescales. Having more halfway points creates more opportunities for the naturally occurring re-evaluation of performance. It also allows the team to develop the skill of reflecting on how they work, and to accumulate more shared knowledge, through having been through this process more often.

It helps if these smaller units are meaningful, discrete units, rather than arbitrary milestones. If you’re using Scrum, each sprint creates a ready made deadline for the team. Pay attention to the conversations in the team around the middle of the sprint. Is there any talk about how little time is left in the sprint and how much work there is to do? If there is, use the opportunity to help the team improve. If there is no discussion, maybe the team does not think the end of the sprint is a firm deadline to deliver something that is done, so that’s a different conversation you need to have.

Each team can have its own way of doing things. Team members may have a relaxed attitude, or a get stuff done approach, or be very congenial. This vibe (also called the “climate” of the team) can be fine and effective until someone thinks it needs to change, then it can be a significant challenge to create a new vibe.

UCLA researcher Connie Gersick was studying how task forces “actually get work done”, and found that how the teams approached their work can be established early and unknowingly. When the team first meets, the way team members work can be established in the first few minutes. Importantly, this was done without discussion, rather than being discussed openly and decided upon. Some teams Gersick studied would be relaxed about their work, and others would be focused on the getting something done quickly, for example. The teams would stick with this approach through the first phase of their time together, no matter if the approach was right or wrong for the task that the team was assigned.

Getting it right from the start

The lesson for us is to be careful about how we approach our first meetings with teams. We need to make sure the way the team is going to do their work is openly discussed when the team is first together, and make this explicit to everyone in the team. This way we intentionally create the right vibe, before it is set in the team.

A cohesive team is great to be in. There is energy and focus within a cohesive team that makes the team stand out from others. Not only does it feel good, but cohesion has been shown to be related to a bunch of good things: team performance, team efficiency, team members putting in effort out of hours, lower absenteeism. So what is the magic of cohesion, and how can you get some for your team?

First, what do we mean when we say “cohesion”? As is often the case, the most vivid expressions come from people we’ve worked with:

 “[Cohesion is] .. when you stay up late or back at work to get something done, because you know the people you are working with are doing the same, and YOU ALL need to get the job done.”

– Participant in Science of Teams workshop at AgilePT, Porto, May 2015

We all have a feel for what cohesion looks like in practice, but in order to assess it and work with it, it’s important to note that it comes in two different flavours:

1. Social cohesion is probably what people first think of when you mention cohesion. It’s a shared liking or attraction to the group, emotional bonds of friendship and caring among group members, and enjoyment of each other’s company. This is the team that has lunch together because they want to spend time together, this is where the team members talk about how great the team is, this is where you feel good about working in the team.
2. Task cohesion is a team’s shared commitment to their goal, as well as motivation to coordinate team efforts to achieve common work-related goals. Teams that have people that don’t particularly like each other, but nevertheless work hard together to get the job done, are high on task cohesion. This is the team where everyone wants to achieve the team goal and puts in the effort to get it done.

So which kind of cohesion was our workshop participant from Portugal talking about?[1]

Out of the two types of cohesion, social cohesion is easier to instil in your team. But while social cohesion does contributes to productivity and efficiency, task cohesion contributes more.

Getting some cohesion

• Suppose you have a team with people who don’t know each other that well. How can you build the cohesion they need to form an effective team? Let’s start with some social cohesion. Pair people off; they’re going to talk to each other for 10 minutes, then move on to another pairing. The task of each pair is to discover as many things that they have in common as possible (from both inside and outside their working life).
• Task cohesion is tougher. Clarifying shared goals is an effective way to build task cohesion. Using the “Product box” method, where the product is the team, can do this in an enjoyable way. The team also ends up with a handy artifact they can use to decorate their work area.
• Another way to increase task cohesion is to use group-based rewards, not individual ones.

[1] It was task cohesion, but there’s also a bit of social cohesion implied in the reason giving for working back, i.e. that the others in the team are doing it too.

‘Team’. It’s such a buzzword. Or has it passed beyond that, to be a word that we hardly even notice anymore? Anyway, the fate of most buzzwords is to be used so indiscriminately that they become meaningless, and that’s what we think has happened to the word ‘team’. It’s now used to mean any group of people who work together, on any task, of any nature; or even just people who work in the same organisation.

This is wrong, misleading, and unhelpful. It hides a very important distinction between teams and non-teams ..

Consider these three groups of co-workers:

• A group of sales people who sell the same range of products, in different territories.
• A group of workers in a tech support call centre. If they cannot solve the problem themselves after ten minutes, they ‘escalate’ the call to another worker.
• A group of people working on a software project, including developers, statisticians, business analysts, user interface experts, and end users.

Which of these groups would you call a team?

Our take on the question:

The first and second examples are not teams, because the people in them essentially work independently of one another — even though they may work in the same physical space, doing the same thing. It is possible for a person in either of these groups to help another worker, of course, but they are not dependent on one another to achieve their goal. A sale is made by an individual, and a tech support ticket is closed by an individual.

The software development team is different. They are a team, because the success or failure of the project depends not only on all of the team members doing their own jobs, but also on their co-operation. They literally cannot do the job of building the product by themselves.

So, for a manager or team lead, a fundamental question is whether her people work as individuals, or as a team. This leads to important consequences for how people should be managed. A manager of a group of individual workers needs to manage them as individuals. In contrast, a team leader needs to pay more attention to the processes that happen ‘in-between’ the individuals in the team, and the states that occur ‘across’ the individuals in the team.