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

Quite simply, your team members need all the skills required to deliver the product as outlined within the user stories. This would include code writing; user story elaboration; product testing, both manual and automated; and soft skills, including self management.

The team makeup will also be influenced by which agile methodology your team is following. According to the Scrum definition of a team, a team should be stable (at least the core team) for the whole delivery. By comparison, in kanban, the focus is on ensuring the team has all the skills needed to deliver the agreed-upon workflow using work-in-progress limits, putting less emphasis on getting a team to a certain size. Others use a combination of more than one framework, such as Scrumban, where there is a maximum team size but they track flow rather than have set iterations. Depending on which methodology your team will abide by, there will be different considerations when looking for skill sets.

We assume that the traditional role of a developer as a coder is a must for an agile project, and that is generally the case for software development projects where these skills are key. However, it should not be forgotten that agile teams can be used for introducing business process change, in which case coders would not be needed. There is still an argument that developers would be needed, but in this case they would be designing and developing the new processes rather than coding. Similarly, agile can also be used in completely separate industries, such as in the construction of a house, which would definitely not need a developer. Therefore, the context and goals of the iterations also need to be factored in when selecting what skills are needed to make up a team.

Not to be overlooked, it is also critical for an agile team to have business analysis and quality assurance skills, which are usually most efficiently and effectively accomplished by integrating team members with specialist experience in these areas. Their competencies should include:

Business analyst

• Ability to see the whole picture
• Analytical thinking and problem-solving skills
• Facilitation and interaction skills
• Modeling ability
• Ability to think as a customer
• A focus on avoiding waste

Tester

• Ability to take on the persona they are testing
• Ability to think in “what if” scenarios
• Experience in testing methods and principles
• Nonfunctional testing skills
• Coaching ability
• Familiarity in integrating testing early in the process (shifting left)

It is this mix of perspectives that really gives the benefits and value to the business, producing not only working software, but software that is fit for purpose. When listening to collaboration between testers and developers, I have often heard comments like, “I didn’t even think about testing from that viewpoint.”

I had the pleasure of coaching a team that had the right mix of skill sets, as evidenced by the way they all worked well together, more like they were friends than coworkers. Yes, there was the odd disagreement, but everyone worked to overcome them. The daily stand-up sounded more like a casual conversation in a corridor. The iteration planning meeting was a lively debate, and the retrospective sounded like a games night. This team worked because they had diverse skill sets and people with expertise in one or two areas, so there was not a dependency on one key person; everyone was equally valued.

Let the Team Come Together

By thinking about the agile team as a collection of competencies and skills, you can then focus on sourcing people who can enhance and improve your team’s overall process. This means not relying on finding members who are cross-functional people possessing every required skill set, but rather finding experts in the individual skill sets required who can complement and work well with the rest of the team.

Mix this group with support, training, mentoring, and time to get to know each other’s work processes, and watch them grow organically into a high-performing agile team.