A cross-functional team isn’t a bunch of generalists

For the first few years of my Scrum Master career, I had a fundamentally incorrect understanding of what the term “cross-functional team” means.

I thought it meant that everyone on the team could do everything. There was no room for specialised testers, database administrators or business analysts on a Scrum team. And just because someone is a JavaScript guru, that didn’t mean that they could expect to be writing JavaScript code.

Fair enough, I thought. Somehow, though, the team members were less than enthusiastic about the concept. It turned out that it was important to them to be brilliant at their craft. And to be able to be experts, they needed to specialise!

To build amazing products, we need amazing people. As simple as that. Luckily, I was wrong and a team being cross-functional doesn’t mean it shouldn’t include specialists.

This misunderstanding doesn’t seem uncommon. In this article, I will therefore explore the concept of the cross-functional team a bit further.

What does it mean for a team to be cross-functional?

If a team being cross-functional doesn’t mean that everyone on the team can complete every task, then what does it mean?

I quite like Henrik Kniberg’s definition:

Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.

When a team is cross-functional, it doesn’t depend on anyone outside the team to be reach its sprint goal. This means that the team doesn’t only consist of people who are good at writing code. It also needs people who are good at understanding the users’ requirements, designing good user interfaces, making sure the functionality is thoroughly tested and so on.

Again, this doesn’t mean that everyone on the team can do all of that. Just that there’s someone who can perform those responsibilities.

The team is collectively responsible. Not the individuals.

In Scrum, a cross-functional team is collectively responsible for meeting the sprint goal. They all work towards the same goal and it is no room for people saying something isn’t their job.

“I did a brilliant UX design. It’s not my fault the developers couldn’t build it.”

“Well, I suppose technically I did introduce that bug when I wrote the code but it’s the testers job to pick those things up.”

“These requirements are bonkers but, hey ho, I just write the code”

Occasionally, people will need to step outside their main area to do something someone else might have been able to do quicker or better. Maybe that other person is busy or ill. Either way, if picking up that task will get the team closer to the sprint goal than doing something else, people need to be willing to do so.

Why is having a cross-functional team such a big deal?

There are several reasons why Scrum focuses so much on cross-functional teams.

A cross-functional team comes up with more creative solutions

In a traditional waterfall approach, innovation happens primarily at the very start of the project. Any ideas further down the chain are ignored and there are even change management processes in place to avoid such changes.

The cross-functional team, on the other hand, is responsible for all parts of the delivery, including the innovation. As the team members have a diverse set of skills, experiences and perspectives, the solutions they come up with are more likely to be creative.

Eliminating external dependencies helps the team to be more productive

It may seem as if having a business analyst team, a user experience team or a database administrator team, would be more efficient. That way, people would always be doing the things they do best, so their skills don’t go to waste.

The problem, however, with such a solution is the number of dependencies it creates. Avoiding dependencies whenever we can is marvellous as it enables us to:

  • Reduce waiting time. For instance, imagine the developers need a small change to the database. It they have to request that change from the database administrator team, chances are the DBAs have other, higher priority tasks.
  • Avoid work-arounds. When waiting for another team would mean we would miss our sprint goal, we might try and find a workaround instead. Such workarounds not only create extra work initially. They also add more complexity to our code and will require testing and maintenance in the future.
  • Create simpler solutions. If another team needs to do their work ahead of us, may build more or something different than we need, which will make things more complex, for no good reason.

Increased flexibility makes it easier to respond to change

As agile requirements evolve, it is important that we can respond to changes easily.

For instance, let’s say we realise through user feedback that we have missed a special case. Fixing this will require us to first clarify some minor details about the requirements. Then we need some small changes to the user interface and the database, update some of the logic. And, of cause, update the test cases.

If each of those small tasks must be solved sequentially, by a separate specialist team, chances are we’re looking at several weeks or even months to make this change. In contrast, a cross-functional team might well be able to complete all those little tasks in a sprint.

How do we make our team cross-functional?

Creating truly cross-functional teams can be hard and take time. However, by starting with where we are and making small incremental changes, we can increase the cross-functionality step by step. Ask: what can we do right now to reduce our dependencies on those outside of the team?

Don’t try to keep people busy with tasks within their core skills in the sprint

Trying to utilise everyone’s specialist skills to the maximum may seem efficient but will lead to sub-optimisation.

For example, creating a lot of backend functionality that will just sit and wait for a front-end developer to become available is wasteful. Likewise, if the testing is running behind already, pulling in even more development work from the next sprint would just reinforce that problem.

And when everyone is busy doing their own stuff means, they won’t get a chance to learn from each other.

Building up the skills in the team

The ideal team member of a cross-functional team has a deep knowledge in a certain area but also some knowledge in other areas. This is often referred to as “T-shaped skills”. Again, not everyone has to be able to do everything.

One way to find out where the team needs more skills is to help them create a skills matrix.

  1. Let the team to identify the skills needed to do the work.
  2. Create a grid with skills on one axis and team members on the other.
  3. Let each team member grade themselves.
  4. Look at the grid together with the team to see what gaps there are.

For each skill, you’ll want at least two people who can do it. At least one of them should be really good at it.

How to fill these gaps depends on what they are. In some cases, it may be sufficient for people to pair with each other to spread their skills. In other cases, they may need training.

Get rid of single points of failure and bottlenecks.

I recently came across a team who had lost their only tester a few months earlier and the remaining team members were uncomfortable picking up the testing. Instead, they had simply updated their definition of done to exclude testing. “Done”, to them, now meant “The code has been merged to trunk, ready for test”.

Maybe it made sense at the time, when they assumed they would be getting a new tester soon. Several months later, however, they had a huge pile of untested code and weren’t able to release anything at all.

This would have been easily avoided, had they only spread some the testing knowledge in the team while they had a tester on the team. This would also help addressing any bottlenecks just having one tester on the team would create.

Don’t waste people’s skills.

Finally, being flexible, avoiding single points of failure and so on is great but that doesn’t mean we shouldn’t make good use of people’s expert skills.

It would be silly having hard-core JavaScript developers spend most of their time doing manual device testing. That would be wasteful for the company and demotivating for the individuals.

Unless, of cause, they were looking to start a new career in that area.

Share this article
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *