The Unreasonable Effectiveness of Cross Functional Scrum Teams

A question came up from @FilippoDeLuca, “During the #scrum training has came up that to delivery more value, the devs should write QA tests too. What is the point to have QAs then?”

A good question, and one I attempted to debate using 140 character snippets, but it was difficult.  It was difficult because I had not yet crystalized my own thoughts on this.  Thus, this post!

In the Scrum framework, the term “cross functional team” comes up a lot

Most people interpret that to mean, “a team that has some devs, some UI, some qa, some db expertise.”  In other words, a “well rounded team.”  Yes, and no.  Not only does it mean a well rounded team of people with specialization in their respective area, it also means that the team members, over time, become more generalized.  Before I dive too deeply into what that means, let’s talk specifically about why cross-functional teams are so effective.

In a functionally-organized company, that has the design team, the architecture team, the test team, these teams tend to optimize their work according to what they do.

From an organizational dynamics standpoint, the functional team tends to identify more with the other members of their team than with a particular project or product.

Think about that for a moment.  Imagine if the NFL had “the runningback team”, “the quarterback team”, “the widereciever team” and these people were thrown together based on who was available when it was time to win a game.  How do you think that would work out?  Yet thousands of companies throughout the world do this exact same thing when it comes to putting together a team for a project.  The work gets handed off from one team to the next, as the business analysis team hands work over to the design team, and the design team hands the design over to the development team.  The development team hands the work over to the qa team, etc.

The incoming work to each team is, in fact, a queue, and queues along with the multiple hand offs decrease the throughput of the team

Also because of the specialization of teams the learning opportunities are decreased until the dreaded “post mortem” 24 months later.  We can avoid these wasteful practices with a cross functional team that is allowed to see the whole.  In other words, a team with a product focus rather than a functional focus.

In Scrum, cross functional teams increase their performance over time because, similar to the Toyota Production System, each team member is expected to not only execute his or her task, but also be responsible for improving the team’s overall work by constantly suggesting improvements to the team’s process (retrospective).  People can only improve their process if they feel they own it.  They can have a stronger sense of ownership if its the team’s work, rather than the “qa team’s” work.

Multi-Skilled Workers

Now, back to my previous point on multi-skilled workers.  There are a number of reasons to cross train team members.  It helps teamwork, it helps the team make improvements, it helps with the team being more flexible, it decreases risk (the truck factor), and it helps the overall organization because a team member who already knows how to do 4 or 5 jobs can more easily learn another job or move into another role.  This is all in service in building a learning organization (an Agile organization).  If multi-skilled workers are best, why do we tend to have specialists?  This is a concept from Frederick Taylor’s “scientific management”, unfortunately, a lot of those principles are relics from the industrial age.  When we are talking about knowledge workers creating new products for the market.  The evidence clearly shows that a multi-skilled team is better, because the primary activity  in product development is LEARNING.


Sure.  Think about this as potential skill vs actual skill.  How many QA people do you know that have a background in software development or computer science?  How difficult would it be for them to learn how to write unit tests when paired with a developer?  How valuable would it be for a QA  tester to be able to write unit tests at the code level?

What if you have specialists on a cross functional team

You get mini-waterfalls each sprint, where code is not written until requirements are done and signed off on, testing doesn’t start until the development is done, and defects are found late in the sprint (and therefore difficult and expensive to fix… thus spilling out into the next sprint).  A lot of teams start off this way, and though its sub-optimal, it is at least a starting point.  Building a cross functional multi-skilled team takes time and will not happen over night.  However, if its set as a goal and we are consistently moving in the direction of that goal, we will have a higher performing team.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Leave a Reply