Meaning of Cross-functional teams?

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.

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.

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.

> 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.

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;"

and

"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.

I have summarised it here: http://blog.scrum.org/professional-scrum-developer/

HTH.

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.

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.

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.

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

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.