What are "Cross Functional" teams?

A cornerstone of successful agile software development organisations is the “Cross functional team” but what does that term actually mean?

Being facetious, it’s exactly what it says on the tin – a team that’s cross functional. However setting aside sarcasm, maybe the best way to look at it is by breaking it into its constituent parts: “Cross Functional” and “Team”.

The Cross Functional bit

There is a common misconception that the term cross functional implies that members of an agile software development team are Jack-of-All-Trades (and masters of none), able to turn their hand to anything required. While to a certain extent that is the case, in reality what this means is that the team itself should have all the necessary skills within it, rather than the team members. That way the value of having people with deep specialist knowledge in their chosen area of operation is not lost. They need to be aware of those other skills, maybe even have capabilities in them, but they don’t need to really know them provided there is someone else on the team to cover that particular base.

So what are those skills and what is the right mix? Here is my take:

•          Software Development (Coding). On average, ~60% of the team need to be coders
•          Test focussed, ~20%
•       The sort of person who could be a great coder but is primarily focussed on automated testing. Testing is a mentality and it’s important and different enough to require someone who will champion the practice within the team
•          Ops/DevOps ~10%
•       Someone who knows about build/deploy pipelines, networks, etc.: the operational work to deploy and run an application
•          Other specialists. The rest of the team can be made up of people who can provide whatever skills the particular problem requires, the main three would be:

o   Analysts

§  Someone who understands requirements elicitation or system analysis

o   Database people

o   Ux designers

The Team bit

To be effective, the team needs to work together well. It can’t be a collection of mini silos who don’t communicate with each other. Perhaps the team dynamic is almost as important as having the necessary skills and Google have done some very interesting research in this area. The results are covered in this presentation by the inspirational Matt Sakaguchi here https://www.infoq.com/presentations/google-effective-teams . I really would urge you to watch it in its entirety, but the main finding is that there are 5 attributes that are crucial to creating effective teams. In order of importance these are:

1.        Psychological safety – people feel comfortable taking a risk or asking a question and know they will be supported by their team mates
2.      Dependability – the knowledge that team mates will deliver quality outputs and meet their commitments
3.       Structure & clarity – the team has well defined roles and responsibilities, everyone knows what they are supposed to do and they do it 
4.       Meaning – the work has personal meaning to the individual team members
5.        Impact – the team members can see the value they bring to the greater good through their work

And that teams with these attributes consistently outperformed other teams (including teams of “Rockstars”/Superstars) by a significant degree.

The size of the team is also important. If it’s too big there are too many lines of communication for them to be effective. If it’s too small they won’t have enough folk to be effective. Scrum recommends a team size of 7 people +/- 2 (i.e. between 5 and 9 people) and Amazon’s Jeff Bezos famously defined optimum team size as never being so big that they could not all be fed with two pizzas. Putting actual numbers on it can be a bit woolly but there is good science behind it http://blog.idonethis.com/two-pizza-team/ .

Cross functional teams are crucial to success, so it’s worth paying attention to both their make-up and their behaviour.