Team Composition: From Cross-Functional to Self-Sufficient Teams

Since the early days of agile development (and before), practitioners have promoted the idea of cross-functional teams. IT team compositions often included developers, testers, analysts, and others. As agile practices evolved, roles such as product specialists and IT operations were included. In either case, some specialized skilled members were part time and designated as subject-matter experts (SMEs). These teams were called cross-functional because they drew needed skilled members from their functional organizations.

However, as explained in the section of this chapter on aligning organizations to business capability, agile organizations (not just IT) are moving toward an organizational structure driven by capabilities (internal) and products (external). Since these newer-style structures are not designed around functions, the term “cross-functional” loses its meaning. What you need today are teams with “sufficient” knowledge and skill to carry out their goals—whether those are technology or marketing skills.

Autonomous teams need to be as independent of other parts of the organization as possible. For example, traditional IT teams often were composed of analysts, programmers, project managers, testers, database specialists, and more. These members were often “matrixed,” meaning they reported to functional managers (who dealt with personnel and performance matters). Team members usually (more likely, always) had more allegiance to their functional hierarchy than to their project teams. These matrix dependencies and lack of allegiance to project teams resulted in slow progress and poor quality because there was little accountability. The more dependencies you have, the more excuses you have to avoid that accountability. Self-sufficient teams are constructed to reduce these dependencies to the greatest extent possible.

A self-sufficient team should include all the capabilities necessary to deliver the work in its portfolio. A typical software delivery team may have between four and eight skill areas represented. Executive and leadership teams should have similar self-sufficiency—CIO, CFO, VP product development, VP marketing.

In EDGE, one of the major shifts in practice is from upfront detailed planning and analysis to more holistic long-term road mapping; this allows planning to be directionally consistent, yet responsive to new information. The big-picture view is needed to provide the structure to knit together a complex solution. It also provides a point of reference as new learning happens and the details of a plan or design need to be revised.

This shift in thinking represents a major change for individuals who have excelled using traditional practices, so it should be nurtured deliberately by leadership and the Value Realization Team (explained later in this chapter).

Trust Relationships

Collaboration is simply two or more individuals working together to create a product or share knowledge. The core of successful collaborative teams is trust. Indeed, trust lies at the heart of autonomy, collaboration, and effective decision making. If leaders don’t fully trust their teams or if team members lack mutual trust, the result is performance degradation. Figure 9-1 shows the dimensions of interactions along a low to high trust line. We frequently think of these dimensions as existing in relationships among team members, but they also apply to the relationships between leaders/managers and teams that report to them.

A good friend of Jim’s once related a story about his 14-year old daughter, who was having a surly day. “It’s your turn to put the dishes away,” said the dad to the daughter after dinner. Later, the dad confronted the daughter: “Why did you put the dirty dishes away?” To which the daughter replied, “Dad, you said to put the dishes away; you didn’t say to wash them first!”

This is a perfect example of compliance—performing an assigned task but taking no responsibility for the outcome. The daughter followed her instructions—to the letter—even though she knew it wasn’t the outcome her dad desired. “Not my fault; I did what I was told to do.” Compliance interactions have very little trust. Therefore, both parties try to protect themselves from “fault” by having a detailed agreement (in many cases, a contract) and following that agreement even when they know it won’t produce the desired outcome. “Not my fault” is the oft-heard compliance mantra. In the Dilbert comic strip, Wally epitomizes a compliance mentality.

Cooperative interactions are in the middle: They have some trust that may be shaky and some accountability, but staff always keep an eye on a fallback position that deflects blame. Cooperative teams will go beyond written agreements, but they fall back on them when trouble looms.

A truly collaborative interaction begins with a high degree of trust that has been established over time. This level of trust can survive a few glitches. No human interactions, no matter the degree of trust, are glitchless. The secret is talking over the glitch and taking responsibility. A collaborative team takes full responsibility for delivering outcomes within established boundaries. They don’t make excuses or blame individual team members.

Autonomous teams strive for the collaborative end of the spectrum. There needs to be collaborative relationships among team members and between the team and management. Autonomous teams do not arise from statements like “You are now an autonomous team,” but rather from actions and interactions that build trust and accountability.

Accountability and Autonomy

Both managers and team members struggle with accountability and autonomy. Managers have a difficult time letting go of decision making. They are nervous about whether the team can make good decisions, given that the team members may not have the experience of the manager. They are concerned that the team members won’t take accountability or their commitments seriously, or that the manager will be left holding the bag for the poor decisions if things go south. For their part, teams are concerned that managers won’t give them enough autonomy, that they will say the words but won’t let go in practice. Team members may also be concerned about being blamed for something they have no control over (what they don’t realize is that few people are really in “control”). Teams worry that managers will make unreasonable commitments without discussing those commitments with them first.

Neither a team nor its managers become autonomous overnight. They have to build up a level of trust in each other so that their fears about each other are minimized. You could think of the progression using the forming–storming–norming–performing model of team development originated by Bruce Tuckman in the 1960s. Just as teams take time to jell, so the relationship between a team and its managers takes time to jell. But in this evolving relationship, trust (as defined in the last section) is paramount. The underlying cause of many of the struggles mentioned earlier is lack of trust. You might even think of the levels of trust (compliance, cooperation, and collaboration) as a rough correlation to Tuckman’s model. In the beginning, the forming stage, there is little trust and everyone operates in the compliance mode. In the storming stage, people are trying to better understand and appreciate each other. The trust level may reach cooperation by the early stages of norming. By the end of norming and into the performing stage, trust has built to the true collaboration level, and both teams and their managers are performing. Of course, the evolution doesn’t happen overnight; in fact, it may take weeks and even months.

While implementation strategies for building autonomous teams vary, we propose one practice that appears to speed the process: “Trust first.” The tendency of managers is to tell their teams, either explicitly or implicitly, “As you prove that you will be accountable for results, I will give you more autonomy.” At the same time the team members are thinking, “You are just talking about giving us autonomy. We’re going to wait until we see it before we agree to be accountable.” These behaviors slow down the adoption and performance of autonomous teams. The better solution is for the managers to believe, “I assume that you will be accountable for results until you prove otherwise. And, given that we are just starting on this journey, I also assume there will be some misfires, so I will give the team leeway until we all understand how this is going to work.” Team members say, “We will assume a level of trust to begin with and work toward defining what autonomy means in our organization; in the meantime, we will do our best to hold ourselves accountable for results we have committed to.” This second set of comments basically says, “We are going to trust each other first.”

Creating an Environment That Fosters Autonomy

Leaders can take a number of actions to foster autonomy, such as having teams set their own schedule, decide what to work on and who works on it, make their own make-or-buy decisions, and integrate their work with other teams. In Drive, Daniel Pink discusses a company that practices ROWE—a results-only work environment. In this company, employees set their own work hours—completely. It doesn’t matter when or where you work, as long as you get results. However, you might ask about coordination meetings with other teams: How do you schedule them if every team is on a different schedule?

There might be a couple of solutions to this question. One would be to set common hours (say, 10 a.m. to 3 p.m.) when everyone should be at the office for such meetings. Or, given that the teams are committed to their assigned outcomes, you could leave it up to them (trust them) to figure out how to accomplish the needed coordination.

Creating an environment that encourages autonomy requires exceptional leadership—particularly in making the transition from traditional teams. In the beginning, some teams will not want either the authority or the accountability—because to a greater or lesser extent they don’t trust their leaders. They fear accountability without authority. Leaders, in contrast, fear losing control and that teams will make unwise decisions or will shirk accountability. The processes and practices of EDGE may be the easiest to implement in an organization; autonomous teams and adaptive leadership may prove more difficult.

The Value Realization Team

The Value Realization Team (VRT),which replaces a Project or Portfolio Management Office (PMO), plays a key role in change by supporting the right kind of new organization, helping the current organization migrate gradually to the new one, and providing ongoing coaching and mentoring. The VRT is not a control-oriented organization like the traditional PMO, but rather a consultative and facilitative one. “Why make the switch from PMO to VRT?” you might ask. If you are just changing the name but keeping the same activities, there isn’t a need to change. However, if you are trying to change the culture so that it focuses on facilitation rather than control, a new name can help bridge that gap—it can turn the constraints of existing governance processes into helpful supporting behaviors.

The VRT focuses on accelerating the delivery of value. It has primary responsibility for facilitating the EDGE processes, maintaining the integrity of the EDGE methods and artifacts, and coaching and mentoring people in developing a continuous learning mindset. Ultimately, the power to “fix things” resides with the portfolio owners and delivery teams.

The VRT is typically smaller than a traditional PMO and is primarily staffed by coaches, facilitators, and analysts. The overall intent when establishing such a team is to resolve systemic organization-wide challenges and to lighten the burden on teams and leaders while maintaining sufficient governance.

Governance and reporting should be both lightweight and effective. The VRT helps teams develop reports that are meaningful, quick to construct, and built into the way teams do delivery. To protect the integrity of EDGE, the VRT also checks that prioritization is done consistently, that investment allocation is revisited in a disciplined and regular way, and that people are following through with their leadership and ownership duties.

One challenge with mixed skill teams is that members need a means of support, career development, and skills sharing. The VRT helps foster communities of practice (CoP), a type of cross-cutting affinity group that links the practitioners in a domain (business: marketing, finance, operations; or IT: user experience, product specialists developers) to others with an interest in the field. The VRT should not run these CoPs, but the team members can provide both guidance and nurturing to the communities and their leaders.

The VRT should ensure that the current state of investment be easily accessed by looking at information radiators. Resource allocation and progress should be visible. This includes sharing what bet and initiative teams are working on and which teams have additional capacity.

Portfolio Teams

We often think about delivery teams at the level of producing software code, but fail to think about teams at every level—from vision to delivery. In EDGE, the processes and practices are fractal in that they are similar at every level, but may operate on different artifacts. For example, an executive team determines goals and priorities, whereas a delivery team determines small slices of business functionality and their priority—but the processes and practices are basically the same. Every EDGE team type, from executive to delivery, needs to be collaborative, self-sufficient, and autonomous.

A few definitions, or distinctions, are in order. You don’t want to say “goal, bet, and initiative team” (too unwieldy) every time you talk about teams, so the generic term for one or all of these types of teams will be “portfolio team.” A goal team may also be called an executive team, and an initiative team is also a delivery team (a delivery team’s portfolio is more often referred to as a backlog). It is important to note that the same individual may serve on multiple levels of portfolio teams. The “teams” at each level are filled by roles. In smaller organizations, one individual might fulfill several roles at multiple levels; in larger organizations, there might be one person per role.

The “boxes” on the LVT are strategic outcomes. Each needs a multidisciplinary portfolio team to shape and direct it. It’s not the job of the executive team or the VRT to define the approach taken to realize aspirations in each box. Instead, the portfolio teams take a target business outcome and determine how best to bring it about.

The portfolio teams collaboratively develop a robust vision of which drivers, constraints, and opportunities exist in their domain. They’re responsible for defining outcomes, creating the solution, and delivering on the approach. For a portfolio team to benefit over time from learning, shared insights, and growing relationships, members should stay together. The strategic formulation of solution and approach is an intimate collaboration that matures over time and benefits from consistency. When a portfolio team is shared across several initiatives, it should be kept intact. For example, a product owner working on two bets should work with the same technical team on both, rather than having to adapt to an entirely new team.

Self-Sufficient Knowledge

Building self-sufficient teams is much more difficult than assembling people with different skills into teams: It requires management attention throughout the organization. For example, commingling technical and business people is a challenge—as illustrated by the tension between meeting business goals, meeting customer needs, and utilizing good 178technical practices within the constraints of time, cost, and quality. Practitioners of extreme programming advocated a number of technical practices such as refactoring and pair programming. Scrum practitioners, by contrast, started with sprint planning and daily stand-up meetings. Ardent agile practitioners voice concerns that the technical practices of agile are undervalued in many agile implementations. This often heated debate within the agile community itself illustrates the difficulty of melding the disparate views of people from technical and business backgrounds into a coherent whole. Organizations that have figured how to balance and integrate these two aspects have been the most successful.

Self-sufficient teams should have the knowledge and skills to deliver a product. However, sometimes these teams require specialized knowledge for a short period of time. In this case, how far do you go with self-sufficiency on a team? It depends on dependencies. You want wide enough self-sufficiency and decision-making power that teams minimize dependencies on other functional areas or teams. Think of traditional organizations in which business analysts, developers, testers, and operations staff operate in separate functional teams. These teams are dependent on each other at a very low level. Even though they may be working toward the same goal, they will inevitably have different priorities. They will also have different processes and performance metrics that focus more on functional success than on outcome success. With this structure, you go as far as you can in reducing dependencies without creating more inefficiency than it’s worth. At the extreme, there would be zero dependencies (a fully autonomous team), but this approach often under-utilizes specialty resources such as security because you don’t need them all the time.

We have seen far too many instances where the business analysts, developers, testers, and operations groups are at odds with each other, with their conflicts exacerbated by functional performance metrics that operate against producing desired outcomes. In one case, the business analysis group’s performance was measured, in part, by delivery of a “complete” specification document on time. This group inevitably had little time to actually talk to the development team. Furthermore, once the document was “completed,” the business analysts were reluctant to change it. By contrast, the goals with self-sufficient teams are to minimize dependencies and to maximize mutual commitment to outcomes.

Diverse Social Perspectives

Self-sufficient knowledge isn’t sufficient—you also need diverse perspectives. As every management consultant and author points out, the world is shrinking and companies need social perspectives that include diversities based on region, country, race, gender, religion, sexual orientation, and more.

As of early 2019, ThoughtWorks had more than 5000 employees in 14 countries. When working for multinational clients, it is important—no, critical—to bring global perspectives from China, India, Europe, North America, Australia, Brazil, and others to engagements. Doing so may take extra time, and it may be frustrating at times. Even so, bringing diverse social perspectives to your digital transformation is critically important to self-sufficient knowledge.

Some may argue that perspectives based on characteristics such as age or sexual orientation have no place in a business setting. We don’t agree. People spend a significant part of their lives working, so all of these perspectives have great relevance. As many companies have shown, valuing these perspectives can lead to positive social change.

Trust and Respect

For a team to be effective, it needs both trust and respect. Respect entails accepting, and even admiring, that others have the requisite knowledge and experience to contribute to the team. Trust is the belief in the reliability of others, believing that they will, to the best of their ability, do what they commit to doing.

In our tech-driven world, tech skills, knowledge, and capabilities are critical—and often lead to a tech-centric meritocracy in organizations. A potential downside of this meritocracy is a lack of respect for “others.” Developers may disrespect testers. Project managers may disrespect developers. Technologists may disrespect product management. Hardware teams may disrespect software teams. Delivery teams may disrespect management.

Some rivalry between groups is healthy, but disrespect is detrimental to collaboration. Jim once facilitated an off-site design session for a new medical instrument. At one point, several of the hardware engineers made a disrespectful comment about software developers. Called out on his comment, one engineer sheepishly said, “Oh, we weren’t talking about the software developers on our team; we were referring to the group back at the office.”

Respect doesn’t necessarily imply that all team members contribute equally to success. On basketball teams, for example, there are stars—like Lebron James—and role players. Without the role players, the stars won’t succeed, but everyone understands that the stars may determine ultimate success. On good teams, there is mutual respect among all the players, even as they recognize the differing contributions of various members. Everyone contributes and is part of the win.

Open to Others’ Ideas

Innovation begins with openness to ideas, even the bad ones. Openness is closely tied to trust and respect, as it is difficult to be open when these behaviors are missing. Team members need a fundamental belief that ideas can progress from good to better to best by integrating multiple perspectives into a final product.

We once worked with a team in which one member was always bringing up multiple reasons why someone else’s idea wouldn’t work. This member, who was very knowledgeable about his subject area, was very astute at generating problems with new ideas. This, of course, put a damper on other team members’ willingness to voice their ideas. One day we approached this naysayer with a challenge: “Today, we don’t want you to say anything about why ideas won’t work. We want you to only voice your own ideas to address the issues.” He couldn’t do it! It made him realize how difficult it was to think up new ideas and he thereafter tempered his negative comments.

It’s not that you want to ignore issues with ideas, but rather that you need to encourage multiple ideas and then later subject them to practical implementation discussions. Intentional processes can also help brainstorming sessions—for example, separating idea generation from idea analysis.

Facilitators

To be effective, every self-sufficient team needs one or more skilled facilitators. Teams hold many different types of get-togethers: daily stand-ups, brainstorming, retrospectives, showcases,⁹ and more. Some types of meetings, especially those with larger groups of people, require greater facilitation skills. Ideally, some volunteers from the team will be interested in gaining or enhancing these skills. They will keep everyone involved, keep meetings on track, and nudge participants into making good decisions. A good facilitator can mean the difference between boring, unfruitful meetings that go on and on, and meetings that produce results in a timely manner and leave the participants energized. Good facilitators help turn groups of people into jelled teams. Having people with the right self-sufficient skills and experience on a team isn’t enough—you need someone to tie them together. Every self-sufficient team needs members with facilitation skills.

9. A showcase is an end-of-iteration presentation of a working application to the clients or customers.

Slow Decision Making

An oft-quoted problem raised about collaborative decisions is that making them is too slow—too much talking, not enough deciding. While this can be an issue, good teams know that the process can actually be considerably faster:

• Some decisions can be made by subsets of the full team, or even by the leaders.

• When everyone has participated in the decision, they are likely to be more committed to its implementation.

• Slow decision making is often the result of poor understanding of the goals or MoS of the initiative.

• Slow decision making is often the result of poor facilitation.

When people complain about slow team decisions, they are generally thinking about one-off decisions, not a series of decisions that the team needs to make. Good teams accelerate the process from one decision to the next by carrying forward a good understanding of the goals, bets, MoS, and other contextual information. They don’t have to rehash the meaning of the goals or other items. The discussion of these items may take more time in the beginning until the entire team becomes comfortable with their understanding, but little time thereafter. If the team continues to debate goals and other underlying precepts, it is a strong indication that something is wrong. It is similar to the issue with some agile teams when they get lost in the details of weekly iterations and lose track of their outcome goals.

In teams that are not self-sufficient or co-located, it may take days or even weeks to find time to meet and make decisions. Agile teams, which are usually co-located either physically or electronically, can use daily stand-up meetings to make minor decisions on the spot, or convene meetings quickly to discuss more consequential decisions. Furthermore, on more traditional teams in which members don’t work together in close proximity, those members often don’t know each other very well, so their decision making takes more time as they try to understand each other’s positions.

Willingness to Participate

How many times have you worked in a team in which one or more members tended to sit in the corner, working away by themselves? These same individuals are reluctant to attend meetings or group discussions. Granted, everyone needs alone time, but that is different from unwillingness to participate. We once worked with a client whose developers had individual offices and where a knock on the door with an inquiry like “Can I ask you a quick question?” was often met by the response “Send me an email.” This was a company in which technical meritocracy was embedded in the culture and staff had little incentive to interact with others. This was a very successful company for a lengthy time—but its innovation also suffered over that span.

Having individuals who participate fully in the team can determine the level of success. But there can also be over-participation—excessive meetings that drain the members’ enthusiasm for team activities. As in other areas, balancing rules the day, again.

Aligning Organizations to Business Capability

An LVT is aligned around outcomes of customer value at every level. Traditionally, many business and technical organizations have been organized around functions. For example, at the IT delivery team level (initiative), organizational structure was often functional—developers, testers, designers, database specialists, and more. Individuals in each of these groups tended to work part time on project teams, but they identified more with their functional areas than with the teams. Project teams tended to remain together only for the duration of the project. The functional breakdowns in IT mirrored the stages in a waterfall or serial approach to software development.

Having an LVT aligned around outcomes and an organization aligned around functions is a misalignment of people to desired outcomes. Depending on the maturity of your organization’s agile practices, you may have broken down some of the silos: Developers, quality assurance testers, and analysts/product people may already be on the project teams simultaneously. If your organization has embraced continuous deployment and evolutionary architecture, enterprise architects and delivery infrastructure teams may already be working in concert with the team as well. Figure 9-2 shows self-sufficient teams at each level of the LVT structure.

As organizations become customer-centric, marketing and design functions begin to play a focused and crucial part of the cross-team collaboration needed to effectively balance the demands of the business, the needs of the customer, and the technical practices needed to build great products. Thus, in your new organization, you want to:

• Institutionalize and expand self-sufficient teams to be longer-lived teams aligned on product or business capability.

• Expand lean concepts into the business by increasing business involvement in portfolio teams.

The first significant transition for organizations was from functional to self-sufficient teams, although in the beginning many agile teams¹⁰ were limited to technical roles. From the earliest stages of agile software development, proponents recommended cross-functional (now self-sufficient) teams. Perhaps they tended to focus on stories (user requirements), which were written in business terms, but the early agile teams didn’t focus on outcomes. The agile projects were often managed by traditional project management practices, including measuring conformance to scope, schedule, and cost plans. While these agile teams offered improved performance over traditional development approaches, there was still much room for growth, as they improved on delivering stuff, but often did not deliver the right stuff.

10. Non-agile teams also went through this transition from functional teams to crossfunctional teams.

The second transition in changing organizational alignment was from a project orientation to a product orientation, as shown in Figure 9-3.¹¹ This step expanded the skill areas included in the project team—most notably including product and tech operations staff. Agile teams began thinking about delivering and prioritizing stories using customer value. The technology organizations began switching from a project hierarchy to a product hierarchy in which product teams tended to remain together far longer than project teams did. The alignment between outcomes and organization improved, but there was still more to accomplish—including increasing business participation and eventually realigning business organizations. As organizations became customer-centric, marketing and design functions also played a focused and crucial part of the cross-team collaboration needed to effectively balance the demands of the business, the needs of the customer, and the technical practices required to build great products.

11. Public-sector organizations such as government and nonprofit organizations may want to substitute the term “client service” for “product.”

The third type of transition has been from project to capability, as organizations commit to outcome goals. This realignment includes both technology and business areas of the organization. This typically happens as organizations become customer driven from the outside in, rather than from the inside out. Desired customer value outcomes are then supported by business and technology capabilities, rather than by functions.

Business capabilities for an online retail company might be, for example, order processing, merchandising, catalog management, and customer billing. Unless the business changes significantly, these capabilities will be required for a very long time. Because a retail firm will always have a merchandising capability, it will therefore always need support and expansion of those digital assets. This logically leads to long-term technology and business groups dedicated to supporting this capability—from the executives to the delivery level. Another example would be the function of inventory management versus the business capability of order fulfilment. Fulfilling an order requires a number of business functions, such as inventory control, accounting, and shipping.

The big shift for organizations is to move from “part-time” transient project assignments of people, to dedicated longer-term product and business capability area assignments. That needn’t mean people are stuck; it just means teams need to focus on a product/capability area. People can certainly move around, but in a responsible way. Roles must be backfilled and time must be given for people to get up to speed when they enter a new domain.

We prefer long-lived product/business capability teams to shepherd initiatives and the assets in their area, so that they not only create and deploy something but also support it. This encourages responsible tech debt management and quality practices. It also allows teams to sunset assets more quickly, thereby saving money and support time. Being responsible over the long haul reinforces the types of behavior that build value continuously.

A mix of product and capability alignment will be evident in many organizations, particularly software product companies. Software companies may choose to have a product alignment for their products, maintaining a customer value fitness function and a capability alignment for internal applications.

The end goal of these realignments is to have long-term teams of technology staff supporting product/business capabilities and measuring success based on achieving desired customer value outcomes. You probably won’t reach this lofty goal in every part of your business—but successful digital enterprises will increasingly embrace this type of alignment.

Final Thoughts

In EDGE, we have been pursuing three key questions: (1) How should we invest?, (2) How can we adapt fast enough?, and (3) How should we work together? You might have an incredibly sophisticated portfolio investment process, but without the right organizational changes, your portfolio plans will expire on the petard of execution.

This book isn’t about the normal course of business: It’s about digital transformation, which means innovation, creativity, and speed. You won’t achieve these results without the trio of autonomous teams, collaborative working and decision making, and the cultural changes outlined in Chapter 10, Adaptive Leadership. Answering the question of how you work together will drive the continuing success of your digital transformation.