Making 1 + 1 + 1 + 1 > 4

How we use Agile to provide improved mobile and online solutions for financial services

Teamwork is core to the Agile way of working. How do you create a high-functioning team that can produce more than a sum of its parts?

I recently attended the Agile Business Conference in London. The closing keynote was one of the more memorable sessions of a great two day conference: a talk by Eben Halford exploring what makes a team different from a group of individuals.

It got me thinking about our teams here at Intelligent Environments, how they are structured and why they work so well together.

Team-shaped work

‘Team-shaped work’, a phrase Eben discussed, is about work that is best accomplished by a team rather than a group of individuals. Take the Formula 1 pit crews as a notable example. The work they are given, perfectly fits the team “shape”, governed by their size, experience and skillset. They also work together as a tight knit team, perfectly co-ordinated and constantly collaborating. Each member is totally aware of what others around are doing, the impact of every action and the dependencies between each task.

It’s clear to anyone who’s seen F1 pit crews at work that they are so much more efficient than a single mechanic tasked with all stages of a pit stop. It’s also clear that adding more mechanics, supervisors or assistants to the team is only going to hinder this high performing team.

At Intelligent Environments, our product development teams usually have 5 members and we always look to maintain a balance of experience & skillsets within the team. We’re also very conscious that the type of problems that we ask teams to solve are matched well to the shape of the teams.

We’ve all come across ‘one man bands’ in the software development world. One developer who’s associated so deeply with a feature or piece of code that no-one else can add value. It’s a vicious cycle as it’s so tempting to allocate work to specific individuals based on their skills and previous experience.

Test automation at Intelligent Environments is a great example of how we try to avoid ‘one man bands’. This domain is led by the QA analysts in the team, but everyone participates. If someone should suddenly go off sick or become unavailable for any other reason, test automation doesn’t grind to a halt. Instead other team members swarm around these duties to ensure testing progresses to plan.

I’ve previously encountered a situation where the team lead was responsible for packaging all releases. As a specialist in this task he was fast and efficient, but if he was ever unavailable we would have been unable to release.

Short-term pain for long-term gain – flexibilty produces productivity

We spent some time ensuring other team members were also able to package releases, with a focus on ramping up their skills and, granted, they were a little less efficient in the early days. But it meant we had the long-term flexibility needed to ensure our teams would never grind to a halt because the release could not be packaged.

Overcoming that single point of failure will almost certainly bring some short term pain, but you will be rewarded with an extremely valuable medium- and long-term gain: an uplift in team flexibility that shows itself in increased team productivity.

Graph showing how productivity temporarily declines as once-specialist skills are shared amongst the team before recovering to offer increased productivity for the long term

So am I saying that every person in the team should be trained to do every feasible task?

In reality, that simply isn’t feasible. Technology stacks are becoming more diverse and more complex; added to that DevOps is blurring the boundaries between traditional development and operations domains.

Expecting every team member to know everything about every stack, every language and platform we use and every task within the scrum would mean they spend more time simply trying to keep up than building solutions. A balance has to be met.

That balance comes in the shape of the T-shaped developer. A T-shaped person has deep knowledge in a small number of areas and breadth across many more. Nigel, for example, is a .Net specialist. He will also know enough to pick up some JavaScript from Jane when there are still has some front-end transitions that need sorting out. He may not be a JavaScript whizz, and he may ask Jane to pair up on a few areas, but by actively collaborating they’ll do a sterling job.

T-shaped people working together form a higher functioning team – a team where the value of the whole exceeds sum of the individuals. Each may have his own individual skills and specialities, but when you bring them together they complement and support each other in a way that is completely natural and totally fluid.

Turn your focus to the team

Joel Spolsky famously discusses a ratio of 10:1 in the productivity difference between good and great developers. In his recent book “Scrum – The art of doing twice the work in half the time” Jeff Sutherland discusses a parallel study of teams, but amazingly showing a 2,000:1 ratio.

So, if you want to be up there with the best, start by looking at how you can improve your team dynamics ahead of simply how to improve individual’s skills.

04 Nov 2015

How we use Agile to provide improved mobile and online solutions for financial services

Teamwork is core to the Agile way of working. How do you create a high-functioning team that can produce more than a sum of its parts?

I recently attended the Agile Business Conference in London. The closing keynote was one of the more memorable sessions of a great two day conference: a talk by Eben Halford exploring what makes a team different from a group of individuals.

It got me thinking about our teams here at Intelligent Environments, how they are structured and why they work so well together.

Team-shaped work

‘Team-shaped work’, a phrase Eben discussed, is about work that is best accomplished by a team rather than a group of individuals. Take the Formula 1 pit crews as a notable example. The work they are given, perfectly fits the team “shape”, governed by their size, experience and skillset. They also work together as a tight knit team, perfectly co-ordinated and constantly collaborating. Each member is totally aware of what others around are doing, the impact of every action and the dependencies between each task.

It’s clear to anyone who’s seen F1 pit crews at work that they are so much more efficient than a single mechanic tasked with all stages of a pit stop. It’s also clear that adding more mechanics, supervisors or assistants to the team is only going to hinder this high performing team.

At Intelligent Environments, our product development teams usually have 5 members and we always look to maintain a balance of experience & skillsets within the team. We’re also very conscious that the type of problems that we ask teams to solve are matched well to the shape of the teams.

We’ve all come across ‘one man bands’ in the software development world. One developer who’s associated so deeply with a feature or piece of code that no-one else can add value. It’s a vicious cycle as it’s so tempting to allocate work to specific individuals based on their skills and previous experience.

Test automation at Intelligent Environments is a great example of how we try to avoid ‘one man bands’. This domain is led by the QA analysts in the team, but everyone participates. If someone should suddenly go off sick or become unavailable for any other reason, test automation doesn’t grind to a halt. Instead other team members swarm around these duties to ensure testing progresses to plan.

I’ve previously encountered a situation where the team lead was responsible for packaging all releases. As a specialist in this task he was fast and efficient, but if he was ever unavailable we would have been unable to release.

Short-term pain for long-term gain – flexibilty produces productivity

We spent some time ensuring other team members were also able to package releases, with a focus on ramping up their skills and, granted, they were a little less efficient in the early days. But it meant we had the long-term flexibility needed to ensure our teams would never grind to a halt because the release could not be packaged.

Overcoming that single point of failure will almost certainly bring some short term pain, but you will be rewarded with an extremely valuable medium- and long-term gain: an uplift in team flexibility that shows itself in increased team productivity.

Graph showing how productivity temporarily declines as once-specialist skills are shared amongst the team before recovering to offer increased productivity for the long term

So am I saying that every person in the team should be trained to do every feasible task?

In reality, that simply isn’t feasible. Technology stacks are becoming more diverse and more complex; added to that DevOps is blurring the boundaries between traditional development and operations domains.

Expecting every team member to know everything about every stack, every language and platform we use and every task within the scrum would mean they spend more time simply trying to keep up than building solutions. A balance has to be met.

That balance comes in the shape of the T-shaped developer. A T-shaped person has deep knowledge in a small number of areas and breadth across many more. Nigel, for example, is a .Net specialist. He will also know enough to pick up some JavaScript from Jane when there are still has some front-end transitions that need sorting out. He may not be a JavaScript whizz, and he may ask Jane to pair up on a few areas, but by actively collaborating they’ll do a sterling job.

T-shaped people working together form a higher functioning team – a team where the value of the whole exceeds sum of the individuals. Each may have his own individual skills and specialities, but when you bring them together they complement and support each other in a way that is completely natural and totally fluid.

Turn your focus to the team

Joel Spolsky famously discusses a ratio of 10:1 in the productivity difference between good and great developers. In his recent book “Scrum – The art of doing twice the work in half the time” Jeff Sutherland discusses a parallel study of teams, but amazingly showing a 2,000:1 ratio.

So, if you want to be up there with the best, start by looking at how you can improve your team dynamics ahead of simply how to improve individual’s skills.