How to make your agile team work?
September 2019
Implementing an agile approach in already existing corporate is usually a painful and long-lasting project with an uncertain result.
The modern business environment is a hub of rapid change. As they say in Silicon Valley, ‘it’s no longer big eats small, but fast eats slow.’ Stability rather than change is the most dangerous state for any business to be operating in.
Only twelve years ago, the companies with largest market capitalisation were predominantly in the sectors of oil and finance (i.e. GE, Total, Citibank, ExxonMobil); now, technology has replaced this headline line-up with the likes of Google, Apple, Amazon, Facebook and Alibaba. Companies offering web services, social connectivity, increasingly affordable technology and knowledge.
Furthermore, with this new, increasingly affordable technology eroding previous barriers to market entry, disruption is currently sweeping across several industries, including retail, banking, transportation and hospitality. No longer prevented by high start-up costs or difficulty identifying and accessing suppliers, today, even the smallest enterprise can reach a global market and disrupt a well-established industry, seemingly out of nowhere; and, all without ‘owning’ or ‘providing’ very much in the traditional sense.
In this ‘fast eats slow’ environment, agility is everything. Businesses need teams and individuals who stay alert to industry threats and opportunities, can sustain performance during change, and be adaptable in a whole range of ways.
As organisations respond to this more volatile business context, one noticeable shift has been the increasing prevalence of temporary teams. Next we’ll briefly explore the types and variations in temporary team structure, before outlining how to, as Amy Edmondson puts it, generate ‘high performance on the fly’; ensuring your temporary team accelerates straight through to high performance.
The rise of temporary teams
As organisations look to become more agile, temporary teams assembled on the fly are becoming increasingly common. These teams can be reactive, for example you may have heard of socalled ‘cheetah teams’, who are formed quickly to deal with unexpected events; or the recently termed ‘ant teams’ who prepare for harsh times ahead. Either way, temporary teams enable organisations to reallocate resources quickly as they continuously adapt to new client demands and industry changes.
Key challenges for temporary and agile teams
At Lane4, we define a temporary team as one with diverse expertise assembled to work on a specific time-bound task. This team can be proactive or reactive in nature, but it can also vary in both the familiarity of the task and familiarity of the members. For example, team members could be highly familiar with the type of project being executed but completely unfamiliar with each other; or perhaps known to each other, but dealing with a novel task.
Key challenge: how do you build trust without time?
One of the key challenges when there’s low familiarity between team members is trust. Often, people talk about allowing trust to ‘build over time’, but in these temporary teams this isn’t an option. They need to develop what’s known in the research as ‘swift trust’. So how do you build swift trust in a temporary team?
Luckily, temporary teams are far from new. In the military, healthcare, crisis response, movie production, theatres, and aviation they are, and have for a long time been, the norm. Researchers in these fields of performance have been exploring how to build ‘swift trust’ for years.
From this research, three factors have emerged as essential to build trust quickly and enhance performance in temporary teams, namely: group-based predictions, role clarity and collective responsibility. We’ll briefly explore each of these factors in more detail:
1. Group-based predictions
Imagine. A new team forms. High performance is critical. You need to be able to predict how others in your team will respond. You don’t know them, but your brain forms trust depending on what you do know, namely information about the organisation, team, or role they represent.
For members of flight crews, teaming up with strangers is their working way of life. Individually they know their task inside out, but as a team they only fly together for two or three days at most. On top of that, they have the ultimate high stakes goal of getting people from A to B. Swift trust is essential.
In flight teams, research shows trust hinges on predictability, with crew members wanting to be able to predict what someone will do under certain circumstances.
Personality and team profiling is a great way to create a common language and group-level knowledge around certain personality types; enabling teams that are relatively unfamiliar to quickly gauge how someone behaves or, for example, likes to communicate or be communicated with.
2. Role clarity
This may sound simple, but to develop swift trust it’s vital to establish role clarity early on in the team’s formation. Role clarity refers to much more than just understanding your own role in a team. It’s about being clear on who’s in the team (i.e. the inner and outer circle of resources team members can draw on), knowing how your role fits within a wider strategy, as well as having a working understanding of the role and responsibilities of others. Teams should also clarify upfront where the decision boundaries lie within the team; who makes the final call on what aspects of the project?
3. Collective responsibility
It’s easy to assume everyone’s working towards the same goal. However, there’s a big difference between ‘doing your bit for a project’ and collective responsibility. Both involve working towards the same goal, but team performance dramatically increases if it’s clear everyone is responsible for efficiently delivering one outcome goal. When people know they are jointly responsible for one final outcome, not just ‘their bit’, they are more likely to adapt their plans to support others, feel safe to ask questions, clarify points and provide updates.
Top Tips How to build swift trust and enhance performance of temporary and agile teams
1. Support mutual know-ledge in your team
Is there a way people can quickly and accurately gauge someone’s working preferences and how they may react in certain situations?
2. Establish clear roles
How clearly do people understand each other’s roles and mutual dependencies in the team?
3. Set joint responsibility
Does everyone feel jointly responsible for the outcome? Or, do they perceive themselves responsible for delivering their part of the project?
Case study: Comparison of agile vs. waterfall project team
If you are an agile geek you might find the folowing picture very familiar. The visualization shows how big a difference there is between an agile and regular project team. Typically agile teams are much more connected with the business – the product owner is much closer to the team and communicates more in general (see picture on the right).
Communication, interdependencies, and importance are more evenly distributed in the whole team and within all team members. Such a picture is very common across the industries and supports the team to reflect the need to get the business closer to their solutions.
If you are implementing an agile approach approach into your company culture you will be very probably facing similar situations as the following team.
The set of sociomapping analyses outputs captures a situation in a typical “newly” configured agile team.
- Bad climate in the team due to the transformation with negative impact on team deliveries
- Scrum master very much disconnected
- The rest of the team highly cohesive
- Low importance and value of Scrum master perceived by the team
Facilitated feedback session against the maps helped the team to clarify mutual expectations (between the scrum master, product owner and team lead) and team and led to better integration of the role. The team set-up an easy plan how to utilise the role of Scrum master. Sociomappin analyses have revealed also one additional issue – weak relationship and low mutually perceived importance between the Scrum master and the Product owner. Based on this insight the team has asked to strenghten this specific connection, individual commitmnets by both have been made.