Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Meaning of Cross-functional teams?

Last post 07:23 pm December 16, 2020 by Naresh VK
11 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.

09:08 pm May 8, 2020

There is a basic misunderstanding in agile practitioners in the community that talk about T-Shaped team members. I often wonder if they themselves have ever tried to become a T-shaped skilled. The term cross functionality is so misunderstood in the community that it became one of the reason for resisting change. With that misguidance team members start to think that if they start following agile principles and values they have to learn other skills as well which they don't want to. Asking a QA person to learn coding in python to help team make progress or asking an analyst to learn the same is very easy to advise but it may be hard for the team members. So without understanding what really team wants, these kind of advise does not help to build the team.

Cross functionality means interdependence between team members and all core competency exist in the team, not everybody need to learn everything.

02:46 am May 10, 2020

How I see cross-functionality - While I am not good at Kitchen, in case my wife falls sick one day, I can still cook, rather than get a takeaway. Or, how in armed forces, medical corps are competent to use ammunitions, just in case.

IMO, another reason for the cross-functional team is so that everyone is competent enough to understand, collaborate, and empathize. So, when a developer is talking about a test scenario then everyone should have some basic understanding to participate and contribute inputs. And if a developer is stuck in some technical issue, others empathize with his/her situation and may swarm to clear the flow and limit WIP. Else, we may have competency-based disconnected discussions and individualistic delivery of work.

Also, this helps live the core values of Scrum.

10:31 am May 13, 2020

Hi , Anand Pandey

“How I see cross-functionality - While I am not good at Kitchen, in case my wife falls sick one day, I can still cook, rather than get a takeaway. Or, how in armed forces, medical corps are competent to use ammunitions, just in case.”

I agree this example

07:23 pm December 16, 2020

Hi Anand Pandey, the kitchen metaphor is good but unfortunately working in software or performing knowledge work is not same as working in house kitchen. 

Also, in armed forces, yes everyone is capable of going to war. It is because they are all trained like that have been training every day. Its not like everyday they are going to war. For armed forces the majority of their time goes into training. 

The situation is not same in software development. People are coming from different background, different skillset and also from vendor organization, offshore. They are delivering software everyday, may be sometime they are getting some kind of training. But that's not enough for them to pick up some skills which they are not exposed to for long enough. Again the metaphors are good for trainings but does not apply to trenches. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.