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
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.
User Comments
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?
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.
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).
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.