Cross-Functional Agile Teams

In an agile organization, our primary concern is the flow of value - “concept to cash” as we’ve heard from the DevOps and Continuous Delivery communities. We form a hypothesis on what the market wants, we incrementally deliver and prove out that desire, bootstrapping new business opportunities using the scientific method.

Let’s break down the notion of agile cross-functional teams as they relate to this.

In waterfall style delivery environments, we broke responsibilities out into functional groups, with the idea that when we group a concern like security or operations or user-interface design or marketing, we can streamline that function and perform that task optimally.

Ensuring that each of those concerns or teams function at peak performance feels like we’re doing the best we can.

The trouble comes when we realize that no individual function has any business value; for example, marketing is meaningless unless we have a feature to sell. To deliver value to our stakeholders, we need to pass the work between all of these groups. Often the flow is not just in one direction. Testing finds bugs. Compliance finds legal or regulatory exposures. Security finds vulnerabilities. Developers find ambiguity. Then the value is tossed back to the originating group. This hand-off between groups causes time-to-market to falter.

The work stuck in our organization, queued up between groups, is waste. It has no value to the business until it is complete.

In the lean enterprise, we look at value streams to understand how value flows through our organization. When we do so, we measure things like process and lead time at each stage of progress. Process time is how long the work takes to action. Lead time is how long work sits waiting to be actioned, plus how long it takes to action. Most often what we find in traditional organizations is long lead times, and comparatively small process times.

Within these independent functional groups, people find ways to work better. From management to budgeting, each group is encouraged and empowered to optimize within the group, but the only thing they can truly impact is process time, it is the only thing within their control.

The lead time is impacted most outside the group. When work queues up for a group, we think that the group needs more staffing because they aren’t keeping up with the volume of work. I see this most often with programmers, where organizations seek cheaper labour, outsourcing programming work, or packing more programmers onto a team as if the quantity of coding had much to do with the reduced flow of value.

When we measure the value streams in an organization, we begin to see what’s going on.

Looking at the system of interconnected groups and measuring the flow of value across that system, the dysfunction becomes visible. Because quality is so often a down-stream concern, it was some of the first “fat to be trimmed” from an individual group. In software, this looks like barely validated marketing initiatives, ambiguous or incomplete requests for functionality, code that becomes harder to maintain over time, programming errors as this complexity rises, defensive testing practices, and so on. Frustration builds between the groups, assumptions of incompetence, tighter process constraints, reduced communication, and a general hardening of the walls between them.

In the sparse places where communication continues to flow between the groups, we find some improvements, but they tend to lack social support and are often unable to break down the hardened walls. The prevailing culture retains undercurrents of suspicion and even contempt. Security never lets us innovate. Developers can’t deliver code that works. Ops takes too long to provision infrastructure. Business people don’t understand basic logic.

In early agile transformations, it’s not unusual for these groups to inform team composition. A development team. A testing team. A database team. A UX team. A security team. An infrastructure team. A data management governance team. These things seem natural, an echo of the familiar.

Adopting agile ceremonies will not overcome the issue of team hand-offs. There is nothing magical about the daily stand-up, the sprint, or even the retrospective that will solve this problem. Sprints become people communicating status to each other rather than finding better ways to work together. When retrospectives indicate challenges, teams remain powerless to affect the system around them.

The key to overcoming these things lies in the agile concept of the Cross-Functional Team.

The cross-functional team is the team that needs to assemble to carry an idea from concept to cash without having to hand it off to anyone but the customer.

The roles involved in a cross-functional team include product, marketing, experiential design, architecture, coding, testing, deployment, as well as technical and business telemetry to inform future ideation. It may also include auditors, hardware engineers, or other subject matter experts, depending on our industry.

Because the work remains the domain of that single team throughout the whole value stream, we eliminate hand-off delays between teams. Of course, this does require the team to act as a team rather than as a mini-waterfall of hand-offs between people in the group, but that’s the subject of a different paper.

Assembling delivery teams that look like this can be a challenge in an organization due to a general lack of guidance and confusion that arises in terms of reconciling management hierarchy, traditional HR practices, and even residual cultural suspicion between individuals.

Sometimes a role is rare enough that there aren’t sufficient individuals to provide quality contact time for that role within the team. Then we have a choice, we reduce the number of teams, or we increase the number of people that can fill that role.

Because there is no longer anyone else upstream or downstream from the team, the team is wholly responsible for all aspects of quality in front of the customer, and in front of any regulatory agency. They hold full accountability and full responsibility. They succeed or fail as a team.

If there are any roles remaining downstream of the team, they should find nothing wrong with the team’s work. Not a bug. Not a compliance issue or legal exposure. The team will have had all the perspectives needed to address a complete unit of value for release. We may still be building trust at this level, but at some point, we might view any downstream validation as waste or pure compliance overhead demanded by our board.

Chances are, thinking of a team in this way involves a considerable change within our organization. If we believe our bottleneck is typing code, we may have developer-laden teams. If we believe our bottleneck is testing capacity, we may have overbuilt testing teams. Perhaps we have both because the issues resulting from bad code will trigger the reflex to strengthen testing in an attempt to contain those quality problems.

We spend so much time and money containing the damage that our system so efficiently created for us.

There’s no set formula I’m aware of for moving a large organization to cross-functional teams, but I am confident that our first step is to understand the purpose of doing so.

Whether your journey involves cross-functional teams the way we describe in various agile frameworks, or whether you find a new organizational pattern by following lean value-stream mapping, remember your goal: A smooth flow of value from concept to cash.