The general meaning of “cross-functional team” is a team which combines specialists in different
fields that are required to reach the goal.
But it looks like in Agile cross-functionality means not only combining different specialists, but
making them mix. Henrik Kniberg defines cross-functional team this way: “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.”
But where is the line drawn? Is it normal to ask developers to become testers for an iteration if
it is required? Yes, it it. Indeed, I am working with small teams (three developers and one QA) so
many times we find a bottleneck because of having more than one user story in testing so developers
has to stop developing and start testing.
Another good example: I am working with a Legacy code which includes many features and fix in each
release because of that we have a lot of work on testing. If only one team is able to test a new
version the release will postpone or last many time so two or three teams are involving in each
release. Doing on this way we will reduce the time needed to do regression and functional test as well.
Cross-functional can fall into that territory where it is a buzzword that can have various meanings
depending on the company. Some may take it to be the highest level, where a developer could be
anything from a gopher to a temporary CEO and others may view it much more specialized so that it is
different kinds of developers used. A developer may have to be a business analyst, system administrator
or tester or being in charge of database some of the time.
A cross-functional team is not just about areas of expertise but attitude towards getting things done.
The members step up and take on the tasks at hand. You don’t hear, “That’s not my job.”
Constraints on a project are not always technical. Sometimes you don’t have the luxury to hire an expert
at every task and only require everyone to work in their prefered area.
You never want to pull devs away from coding, but in some teams it can’t be helped.