Key Principle: Build Cross-Functional Teams

THIS CHAPTER AND THE NEXT CHAPTER   The fundamental unit of productivity in Agile development is the team—not high-performing individuals, but high-performing teams. This is a key concept, and we have seen many organizations sabotage their Agile adoptions from the outset by not understanding what is needed for Agile teams to succeed and not supporting them in the ways they need to be supported.

The lessons in this chapter discuss structural issues related to Agile teams, and the next chapter describes Agile team culture.

The 2018 Accelerate: State of DevOps report found that, “High performing teams are twice as likely to be developing and delivering software in a single, cross-functional team … we found that low performers were twice as likely to be developing and delivering software in separate, silo’d teams than elite performers” [emphasis added] (DORA, 2018).

An effective Agile team includes the functions or disciplines needed for the team to work independently (that is, be largely self-managed). For work in Cynefin’s Complex domain, much of the team’s work will consist of $probe - sense - respond$. If the team must go outside itself each time it probes or senses, it will not have a timely ability to respond. The team must be able to make decisions on its own about most of its work, including decisions about product details (requirements), technical details, and process details. The bulk of people writing production code should also be creating the bulk of automated test code and sorting out requirements details. Such a team can move quickly in a complex environment and still support the business’s needs reliably.

A self-managed, cross-functional team normally requires at least the following specializations:

• Developers from different layers of the application (front end, back end, etc.) and with different expertise (architecture, user experience, security, etc.)

• Testers from different layers of the application

• Technical writers

• Experts in the development process being used (Scrum Master)

• Subject matter experts

• Business experts who bring business understanding, vision, and ROI to the team (Product Owner)

It’s difficult to assemble a team that possesses the full set of skills needed while staying within the recommended team size of 5–9. Multiple roles need to be played by the same people, and most organizations need to help their staff develop additional skills. The “More Effective Individuals and Interactions” chapter describes practices for doing that.

Beyond skills, a high-functioning cross-functional team must have both the ability and the authority to make binding decisions in a timely way.

Ability to make decisions

The ability to make decisions is strongly affected by how the team is composed. Does the team include all the expertise needed to make effective decisions? Does it include expertise in architecture, quality, usability, the product, the customer, and the business? Or does it have to go outside the team to find expertise in these areas?

A team that lacks expertise in any of these areas will not have the ability to be an effective cross-functional team. The team will often encounter areas in which it does not have the expertise to make a decision. It will then need to reach out to other parts of the organization to access that expertise. This inserts numerous delays. The team will not always know who to reach out to, and it will take time to identify the right person. The outside person will not always be available immediately. It will take time to describe the team’s context to that person. If the team needs feedback on its interpretation of the outside person’s input, that feedback might be subject to many of the same delays. Both the team and the outside person will make assumptions, some of which will turn out to be mistaken, and those mistakes will take still more time to find and correct.

Every team needs to reach outside itself occasionally, but a team that includes all the expertise needed to make most decisions locally can close issues in minutes that would take days if the expertise were not within the team. The team should be set up so that it can close as many issues as possible on its own.

A team of 5–9 cannot have an infinite number of specialists. A common adaptation is to embed less-than-full-time specialists in subjects such as UX or architecture for a few sprints at a time.

Willingness to staff Agile teams with the expertise needed to make most of its decisions locally is a make-or-break issue for Agile adoptions.

Authority to make decisions within its scope

The authority to make decisions comes partly from having all key stakeholders represented on the team and partly from having appropriate permission from the organization. For the team to be effective, it needs the ability to make binding decisions—decisions that cannot be undone by others in the organization.

The absence of adequate authority gives rise to several dynamics, all of them counterproductive:

• The team will spend too much time reworking decisions that have been overturned by others in the organization.

• The team will operate at an overly deliberate pace caused by constantly looking over its shoulder in anticipation of having its decisions second-guessed or overturned.

• The team will insert wait states as it seeks approval for decisions from others in the organization.

Authority and ability must be considered together. It is not effective for an organization to grant authority to make decisions if it does not also create the circumstances that give the team the ability to make decisions. If all stakeholder interests are truly represented within the team, any decision will be considered from all relevant points of view. This doesn’t mean the team will never make mistakes. It means the team will have a sound basis for making decisions, and the rest of the organization will have a sound basis for trusting the team’s decisions.

An organizational unwillingness to delegate the authority to make binding decisions to the team is another kiss of death for Agile teams and Agile implementations.

Standing up self-managed teams

Truly self-managed teams can’t just be instantiated; they must be grown. Teams aren’t always ready to self-manage on Day 1. Part of a leader’s job is to understand their teams’ maturity and provide leadership, management, and coaching to help their teams develop the ability to self-manage.

The role of mistakes

Like any other kinds of team, self-managed Agile teams will make mistakes. That will be OK if the organization has established an effective learning culture. For one thing, the team will learn from its mistakes and improve. For another, knowing that the organization trusts the team enough to let them make mistakes is a powerful motivator.

Test-staff organization

The organization of testing staff has been a moving target throughout my entire career. Once upon a time, testers were integrated into development teams and reported to the development manager. That was found to be problematic because the development managers would pressure testers to “Stop finding so many defects”—which resulted in customers finding them instead.

For several years after that phase, testers were separated into their own group, often sat in a different area, and didn’t report to the development manager. They reported through a different reporting structure that usually didn’t converge with the reporting structure for developers until the level of Director or VP. This structure created new problems, including an antagonistic relationship between development and testing. This antagonism was exacerbated by a “tester as gatekeeper” mentality, in which testers implicitly or explicitly had responsibility for blocking poor-quality releases. The separation of development and test responsibility created a dynamic in which developers abdicated responsibility for testing their own code.

In the next evolutionary phase of the organization of testing staff, testers continued to report separately but were seated with developers to support a more collaborative relationship. Developers would give testers private builds to test, testers would write test cases and share them with developers, and developers would run their code against the test cases and fix many defects before they officially checked in their code. This arrangement worked pretty well for its time in minimizing the gap between defect insertion and defect detection.