Cross-Functional Teams

In the Agile world a cross-functional team is one that has all the skills it requires to get the work finished, without relying on external help. Wow, that’s a mouthful. Let’s provide some examples. A team doing software development might have a mix of the following skills: Development, Requirements Analysis, Quality Assurance, User Experience etc. A team doing marketing work would have a different mix, maybe: Writer, Editor, Graphic Designer, etc. A key detail that often gets lost is that you don’t necessarily need one person for every skill set required in your team. Instead, you need people who already have multiple skills or are willing to learn them (see cross-skilling). These people are often called T or M-shaped people because they have deep knowledge in 1-2 areas and can help out elsewhere.

Ideally our cross-functional team owns the work from the moment a feature or idea is consider until it is delivering value to the customer. (In the software world, this might even include monitoring their application in production). Most teams don’t start with the ideal case, and instead evolve over time to a wider span. (If you understand Lean Principles, a Cross Functional Team owns a Value Stream Map from one end to the other).

Typical initial case:

Example of a team that owns their value stream from end to end:

Traditionally groups are often organized into departments by role or job title – e.g. the Development Department and Quality Assurance group. But cross-functional teams are not departments, and shouldn’t be treated as synonymous. We will explore why departments, often referred to as silos, are not as effective and why cross-functional teams are a better choice.

1. Less time spent waiting - Whenever a team has a dependency on an outside person or team, it spends time waiting for high priority work items to be worked on by others. In a cross-functional team, there is less work that has to be done outside and, even when there is, your team can proceed with lower priority work.
2. Reduced handoff size - In a traditional approach where teams are divided by skill set (e.g. Analysts, Developers and Quality Assurance) work items must be handed off from group to group. The typical outcome is the handoffs grow in size. Errors increase due to misunderstandings and poor communication. Whereas when the work happens within a cross-functional team, there may be still be handoffs but, when they happen, it is with smaller chunks of work. *Ideally teams discover Pair Programming or Ensemble Programming, at which stage handoffs disappear almost completely even within the team*
3. Better communication and co “Us vs Them” - Well maybe not completely eliminating it - nothing is perfect - but certainly far less than before. When the Quality Assurance is part of your team and not another group down the hall, there is less griping about their work and more effort on improvements.
4. Better quality - When Analysis, Development and Quality Assurance are done in collaboration, quality increases due to no handoffs, rapid feedback, work done in smaller chunks, much less time wasted logging defects, etc.
5. Flow - As communication and quality improve, the team will start to spot and resolve their own bottlenecks.
6. Faster time to market - As flow improves, individual features (or work items) get to market with less time from start to finish. (This is often measured as Cycle Time.)
7. Focus on customer - A team aligned to delivering the whole of feature (or work item) is better able to see the customer. In addition, once they have done work to create (or understand) their product vision, they have a common, challenging performance goal.
8. Self-organize - When we don’t have to work across a larger group with formal boundaries, a cross-functional team can organize its own work without adult help.
9. Adaptability - With the mix of skills, cross-functional teams can adapt to changing product or market needs more rapidly and with less disruption.
10. Improved transparency - A team that is delivering complete features (or work items) every Sprint is more transparent, since there is no game of declaring work to 75% done and then blaming the next team downstream when problems crop up. With a cross-functional team, work is either Done or Not Done at the end of the Sprint. There is no 75%.

It is not easy to build cross-functional teams; there are more than a few challenges involved. Nonetheless, the advantages far outweigh the costs. In addition, getting from an initial cross-functional team to the ideal case pictured above may take a long time, but the benefit of small features delivered rapidly that consistently meet customer needs is well worth it.