Do Cross-Functional Teams Mean Cross-Functional People?

[article]
Summary:

Managers who want high-performing agile teams may think this involves finding people who all possess every required skill. But in addition to that being unlikely, it would also be a bad idea; it's the mix of perspectives that really gives benefit and value to the business. Instead, find experts in individual skills who can collaborate well together.

In an agile project landscape, many organizations are moving away from having siloed teams in favor of mixing capabilities within one agile team. By bringing multiple skills brought together, the team can produce better quality results by drawing on their broader range of experiences and differing views to provide a well thought-out approach and product.

Cross-Functional Confusion

This concept of cross-functional teams can cause confusion, however. Agile practitioners sometimes question whether business analysts or testers are still needed, instead designating their duties to developers acting in a cross-functional manner. The language used in the principles behind the Agile Manifesto and in the Scrum Guide—which refer to the technical members of the agile team as “developers” and “the development team,” respectively—has led many to think that only developers are needed within an agile team. People in traditional organizations think of developers as coders. However, the agile guidelines use the word developer to mean “product developer”—any cross-functional role that helps the team deliver the product.

While it is not impossible for one person to have all the competencies, skills, and traits needed to be fully cross-functional, this is highly unlikely. Just as we would not expect a developer to be able to code in every single coding language, it is not reasonable to expect a developer to be skilled in other disciplines such as business analysis and quality assurance. Naturally, all skills can be learned, but the likelihood of developing a team of individuals, each with high-performing skill sets in all cross-functional areas, is a lofty ambition. It is also unlikely that this is the best use of resources—for example, a tester might design tests to give the right coverage based on a strategic methodology, and a developer may not have the knowledge required to do the same.

And just as people have differing competencies, they also are likely to have a bias toward their strengths or areas of personal preference, which can potentially impact the performance of your team. In the example of a cross-functional developer taking on a testing role, this may mean less emphasis on testing their own work, or focusing their testing efforts on areas where they dedicated most of their development time, skimming over others. I have seen developers who test their code from a technical perspective but do not think about how the end-user would interact with the product.

Similarly, from a requirements-gathering perspective, the questions the team asks when eliciting requirements may unintentionally direct the business down a path that aligns with their preference on how to build the product. If developers are left to gather the requirements, they may not include the nonfunctional attributes.

Skills Needed in a Cross-Functional Team

So rather than focusing on cross-functional people, we should focus on cross-functional teams. Consider the following characteristics of high-performing teams:

  • They have the right people on the team
  • They are led from within the team, not managed
  • They understand their mission
  • They communicate and collaborate continuously
  • They are accountable for their results

User Comments

4 comments
Henriette Saarup's picture

I very much agree on the thoughts on the Cross-Functional Team. The different perspectives and experience lead to better refinements and better solutions.

But my big isssue is, that the top 10 user stories on the back log very seldom yield work to everybody on the team in a given sprint. Say you have three developers, two with java skills and one with mainframe/cobolskills. The 10 most important user stories does not require development in the cobol programs. What to do? The mainframe developer can participate in the testing, attend some clarification meetings and sit with the java programmers and watch, learn and discuss. That might go for one sprint, but he will probably get bored and feel useless very soon. So the PO will move some other, mainframe releated user stories up in the backlog.

But now the team start to loose the team-feeling because team members are working on different user stories.

What to do?

 

December 15, 2016 - 10:40am
Leanne Howard's picture

Hi Henriette,

Good question and you can certainly do what you suggest, but I agree that this will not work long term.  It is difficult to tell from your post, but it sounds like the main focus of your development work is not mainframe?  Maybe consider having the developer in mainframe join the team when he is needed, this will need more planning.  You should have all the people with the right skills in the team, but not ones that do not have anything to do.

January 9, 2017 - 7:16pm
Richard Paul's picture

Make smaller teams, then focus on Department cohesion.  We have Teams of 4 with two programmers, who code review each other's half of the story, a business analyst, a QA tester.  We do 1 week Sprints and Stories are generally finished in a week (a sprint), sometimes extending to 2 sprints (or 2 weeks).

March 16, 2017 - 10:58pm
Richard Paul's picture

Oh, and our Business Analyst does all the requirements gathering and User's Guide writing, so we don't have a Product Owner.  QA check User's Guide, BA checks Test Plans, Code Reviewer checks Programmer's Code, and QA tests the program at each stage of development and on the final QA test, it almost always passes because the programmers have had the Test Suite for most of the Sprint and know most of what will be checked, besides some of the ad hoc (exploratory) testing.  Everyone knows the Story because the BA presented it in a Feature Blitz two or three workdays before the Sprint started, bringing in any domain expert that was needed for technical challenges.

March 16, 2017 - 11:04pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.