Cross Functional Teams

In this article I'm going to talk to you about Cross Functional Teams. I am not going to talk about Agile, or Scrum or any other development technique. I am simply going to talk about the benefits of Cross Functional Teams by themselves.

I'm going to show you through a number of examples how they remove blockers from your organization, and how this will help you deliver your code faster with less friction between your teams. By friction I mean conflict, waiting, grumbling about waiting, chucking problems over the wall. Less friction means faster development, but perhaps more importantly better cohesion within your organization and happier people.

What do I mean by a Cross Functional Team though? By a Cross Functional Team I mean a team that has all of the members required to complete a task that brings value to the customer, without the input of people outside of the team. In practical terms this means those teams have a wide range of skills (or functions) within them.

A Cross Functional Team can generate ideas, and take those ideas to the customer, without any other team completing work on a per idea basis to allow them to do that.

A silo style team structure is one where this is not true. Where an idea has to go through multiple teams and have work done by each in order for it to come to fruition.

Cross Functional Teams put the primary goal as being producing value for the business: with consistency being managed by additional processes, Silo style" Teams put consistency within the team as the primary value: with delivering value for the customer being managed by additional processes.

To illustrate the problem Cross Functional Teams solve I'm going to pretend that we're playing a turn based game. So lets take this first example.

It's a plan of work that spans across many teams. In this example I've stuck to three teams, as these are often the most visible from a developers perspective: Ops, Dev, Front. However there are actually loads of teams inside an organization, Maybe there is a Product team, maybe there is a Test, or Marketing team.

This doesn't matter, as even in this simplified example you'll still see the same problems arise.

Lets take our first turn.

In this fictional world we have taken our first step, and both the Ops, Dev and Front teams have completed their turn. As we move into our second turn we're already seeing problems.

Ops have a few questions for Dev, and they're interrupting their new task. Maybe Ops found some bugs, maybe they just need clarification on how something works so they can set something up, or maybe they just want to tell the Dev and Front teams that their bit is running so check the Front and Dev bit.

As minor as this is, it still interrupts other teams work on vital features, and disrupts their flow.

Lets take another step.

Hold up though! Real life doesn't work like this, we don't complete a known amount each turn. Sometimes our estimation is wrong, or scope changes after discovering new functionality.

This is a bit more like it.

Ops found out their work was actually quicker to complete, and Dev a little longer, reliable frontend are going to complete at the time they predicted.

Oh no, now there are two conflicts going on though. The Ops guys are bored, they're trying to get started on the new task, but are being held up by Dev, and Dev are getting frustrated because Ops are badgering them for details on something they haven't even started work on.

On top of this the frontend team are finding bugs in, and asking them about work they completed what seems like ages ago. Everyone is feeling a little harried.

Under increased pressure from the Ops the Dev team are rushing to get finished. What's worse the Front team are being blocked by them too!

It's about this time that the Dev team start cutting corners. I mean with all the bugging of people to get it done, they need to rush. And screw the other teams, they can deal with some of the problems Dev are trying to solve, all they ever do is ask for stuff under unrealistic deadlines anyway. Over the wall the bugs go.

All in all a pretty unpleasant experience for everyone.

Okay, so lets bring this example to a close here. Lets compare this to Cross Functional Teams.

No friction

Still no friction.

Okay this is boring, lets pretend our teams suck at estimation.

Still no friction. Teams can simply bring in more work or push back other work, without blocking anyone.

Okay, so if this makes it so obvious as to why you should use Cross Functional Teams, why do people setup Silos.

Silos happen during the growth of an organisation from a small company to a large company, or during a project that requires lots of skills from one specific type of employee.

In small companies growing to larger companies it makes sense to sit all the employees next to the employees who do similar things to them, as the company is small enough to treat all it's employees as a single Cross Functional Team. As the team grows these groupings get their own tables and managers, and ultimately become Silos.

In larger companies when a project requires lots of one type of employee, such as a major rewrite of a specific component, it's tempting to make a large team all doing the same project, and have only that sort of employee in it and give them a manager. These teams then persist after the project is over. Leaving a Siloed team.

Sometimes it's also that a project that was to work on a specific component that required a single type of employee, then grows in scope to include the usage of multiple types of employee, and rather than split up a working team, these new types of employee are grouped together to form a new team. And like magic, two silos.

From this little example I'm sure you can see that Cross Functional Teams are something that every organisation regardless of what they think of agile should strive towards. The friction from being locked into Silos is always a mistake, and despite it happening naturally sometimes, is not the best position for an organisation to be in.