Meaning of Cross-functional teams?

Last post 11:24 am May 23, 2016
by Bartek Kobylecki
7 replies
05:18 am March 3, 2016

Hi Everyone

Our software teams have been agile for a number of years and the scrum teams comprise developers and QAs, so in a sense we have been cross-functional. (we sprint plan and retro together ) , however, there is still a feeling that we are two teams within one. people are either "developers" or "QAs" and the work is passed between these two sub-teams. I think we can be more efficient as a delivery team if people were able to perform either skills.

Has anyone been through this sort of transition? Is it beneficial? Do you end up with jack of all trades mentality? How do you overcome resistance (ie developers not wanting to test or QAs not thinking they will have the skillset to code?)

Is there any good articles written about teams who have made this transition?

Many thanks.

11:59 am March 3, 2016

There is a debate about the relative merits of cross-functional teams, where all of the skills needed to craft a releasable increment are found within the team, versus cross-skilled individuals, each of whom can perform all aspects of the associated work. The latter can be seen as a potential optimisation of the former. In Scrum, a Development Team member should simply be a developer without a sub-role. A reasonable compromise can be to aim for team members with "T-Shaped Skills", where each has a competence across all areas, and a value-adding specialism that reflects a particular capability or interest.

12:07 pm March 3, 2016

Hi Jonathan,
cross-functional means that the team has all the skills necessary to turn Product Backlog Items into a done Increment.
It does not mean that each member has all these skills.
So your description seems to meet that minimal requirement.
The idea of Scrum is not to force someone into coding who has been testing all his life and is just before retirement.
It is rather to encourage teams to overcome silos of traditional disciplines, learn more and be more robust against unexpected changes (like a tester getting sick). It is indeed beneficial. In the example of "developers" and "QAs" you might notice that the time between a bug emerging and a bug fixed will be reduced drastically.

05:54 am March 4, 2016

That's a good question. I have personal experience of observing a newly formed scrum team where stakeholders were expecting QA to write code - because "scrum says all team members are developers". I believe that's a misinterpretation. QA specialization & role doesn't change just because they are in scrum team & have designation called "developer". A QA personnel's main focus will still be testing just like coder's main focus will be coding & a DB admin will still focus on DB administration - irrespective of all of them now called "developer".

Having said that, to avoid feeling of sub-team within scrum team, cross-learning should be highly encouraged. So QA team members can write automation code & coders can do unit/functional testing.

Another effective way to make it "one team" is to ensure that, team understands the fact that accountability lies with entire team, not indivisual. So a coder can write excellent code but if QA misses to test it properly & defect gets caught by end customer, both coder & QA must take joint accountability & responsibility.

Moreover, management can send this message better by tying up rating/reward system, with team spirit & joint accountability. In traditional system, if rating/reward is given 80% based on personal brilliance & 20% on team spirit - than it should be reversed in case of a scrum team. Under such system, you can be a great coder or tester, but if you lack in team spirit & cooperation, or if your team fails to deliver as whole - than you should be rated lower.

This top down approach probably not 100% in scrum's "self organizing" spirit, but I saw it working well especially in environment where scrum is still not mature. If anyone has better, practical solution, I'll be interested to know.

06:24 am March 4, 2016

> So QA team members can write automation code
> & coders can do unit/functional testing.

For example developers with QA specialisms may author BDD tests and implement the associated harnessing. This genuinely is development work, necessary in order to satisfy a good DoD, where tests constitute part of the increment in order to verify and validate its quality.

05:16 am March 14, 2016

Just remember

"Development team are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;"


"Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole."

The way I see it, it is normal for individual member of the Development Team to focus primarily on their area of expertise.

Cross functionality may come in handy especially when the Development Team are establishing acceptance criteria and test-preparations for the stories in the product backlog. As both testers and coders can attack the story both on Testers/QA perspective and at programmers point of view.

This will greatly improved the quality of the increment.

12:26 am May 23, 2016
11:24 am May 23, 2016

How about running Monte Carlo simulation that would verify what is the impact of specific skills distributed among Development Team members?

Skills should be of course determined by the needs of the project.