For leaders at the enterprise level, an increasingly pressing concern is this: What does an organizational structure that promotes agility look like, and how can we create it? Most organizations are structured as a hierarchy, with specialist departments like marketing, finance and IT. Within this model, projects pass through the organization, and responsibility for any particular initiative is scattered. Things get done only by relying heavily on bureaucracy and management coordination. The bureaucracy may help the organization deliver value—sometimes—but individuals and teams suffer from “permanent part-timer syndrome” and many conflicting priorities. Projects have exceedingly long lead times and get mired in nonsensical process. In today’s environment of constant change, this hierarchical model is a relic. Knowledge workers have a difficult time collaborating with each other and gathering feedback and, when necessary, can’t change course quickly enough to keep up with market conditions.
More and more, enterprises are seeking to shed the hierarchical model in favour of cross-functional teams, and empowering these teams to self-organize.As agile increases in popularity, so does the concept of an organizational structure based on cross-functional, self-organizing teams. The advantages to this approach include breaking down functional silos, moving employees closer to the customer, and motivating a diverse collection of specialists toward a common goal.If the above graphic illustrates what I’ll call the “traditional traditional” approach to thinking about organizational structure, then the graphic below shows the “traditional agile” approach.
There are challenges when thinking about organizing based on agile teams in a completely purist sense. It’s not that organizing around a self-organizing, cross-functional team is wrong—in fact, I would state that it is the true north for any enterprise on the agile journey. But placing everybody on “pure” agile teams is not always practical or economically feasible, and in some situations, it makes less-than-optimal use of scarce expertise. It also can lead to a different type of siloing, where discrete business functions or customer experience teams are don't integrate well. In this case, the organization’s cross-cutting concerns are forgotten, and organizational cohesion can be lost.The agile ecosystemOver the past several years, I have been paying close attention to how others deploy agile at scale, as well as cataloguing my own experiences with customers who want to improve agility. I’ve discovered patterns that describe different ways teams can provide service to their customers, as well as collaborate with other teams in order to provide value. Using these patterns, leaders within the organization are able to agree on a systematic approach to coordinating at scale, creating what I am calling an agile ecosystem. I’ll define an agile ecosystem as a system of self-organizing, interdependent teams that constantly evolve to organize around the delivery of value. The agile ecosystem consists of the teams required to deliver value and the support structure required to enable those teams.The first cohesive unit in the ecosystem is typically a portfolio of teams organized around an explicit mission. These teams tend to share demand in such a way that standing up a common backlog is useful. Each portfolio is designed to minimize dependencies across portfolios, sharing them between different teams within the portfolio.
Some portfolios are based on product families; for example, in a financial services world, portfolios may be based on mortgages, insurance or payments. Portfolios may also be based on channels (such as online/mobile), as well as customer experiences (such as customer acquisition, on-boarding, or retention).Some of the patterns that describe how teams can be organized include:Value Centers: The classic agile team. Dedicated, collaborative, cross-functional and, ideally, co-located. Self-organized and empowered, the team performs activities necessary to create value. Work enters and is completed without any external influences. Traveller pools: Highly specialized workers that are in demand across a number of value centres. This demand can be ad hoc, but when needed, these workers are critical to creating value. Cross-functional or specialist teams can draw from pools of these workers on a just-in-time basis, typically for the duration of the request. UX, middleware and legacy developers are often deployed as traveller pools.Service centres: Like traveller pools, service centres consist of highly specialized workers in demand across a number of value centres. Collaboration within the function is of higher value than collaboration with the upstream value centre. For this reason, work travels to a service centre to be processed by the team, with outputs delivered to the client value centre. If your model has too many service centres, you will have too many handoffs, so try to minimize your reliance on these. We can think about old-school infrastructure and process operational teams as being deployed as a service centre.Enablers: Enablers are often considered “owners” of a specialized capability, and provide explicit services in this capability to value-delivering teams. Services are provided as a platform. Members are sometimes deployed as a pool on teams, sometimes as providers of guidance to a set of interrelated teams. Enablers help value-delivering teams be effective in a certain capability, but empower them to operate in a self-service mode. HR, DevOps and agile coaching teams are all good examples of enablers. Communities of practice: Responsible for stewarding specific capabilities that are important to the overall enterprise. Unlike enablers, communities of practice are typically virtual; membership consists of interested contributors from other teams. Communities of practice share knowledge, but are not owners of any specific platform. Dynamic SWAT teams: A just-in-time team with members drawn from a collection of teams. Often used when teams are collaborating together on larger programs or highly integrated functionality, but the original team structure needs to remain in place (for example, if the duration of the work is not long enough to justify reconfiguring the teams).
When designing a large-scale agile ecosystem, consider crossing portfolio boundaries by connecting portfolios to each other through enablement cores. Each portfolio is likely to have an enablement team, consisting of all the enablers who make sure that value-delivering teams have what they need to be successful. In larger organizations, members of this enablement team may come from distinct enablement cores: centralized teams responsible for enabling portfolios across the enterprise. When thinking about enablement cores, it’s important to remember that the focus is enablement, not command-and-control. Enablers need to make it easy for teams to be successful. Enablers typically go to teams to help them, rather than teams having to go to stage gates to satisfy enablers.A toolkit for structuring an agile ecosystemI’ve spent a good deal of time helping my customers think about agile organizational structure, and have put together an approach to help designers create a system that maximizes agility. The toolkit makes use of a simple modelling notation to illustrate which teams should be doing what and how they can connect with each other. The kit also uses a set of team service delivery patterns and team linking patterns, so designers can take advantage of concepts deployed in field. (These patterns represent knowledge from a multitude of sources, methods, and case studies. Kanban, LeSS and Product Development Flow are all sources of inspiration.)Using this toolkit is not a “one and done” process. The way teams are organized needs to be frequently revisited, based on what is actually in the backlog. The degree to which teams need to change depends on the degree to which the next wave of value will innovate or disrupt the market. New opportunities often require new capabilities and new technologies, which will require organizational designers to completely revisit the existing ecosystem. I know this might sound scary in theory. In practice, however, it turns out that reconfiguring people within a portfolio is not as hard as you might think—provided good agile fundamentals are in place, such as a well structured and highly visible backlog, a collaborative workspace, impediments management, and the right ceremonies at both the team and portfolio levels.Here are the steps for organizing your agile ecosystem:
- Divide the enterprise into portfolios that provide meaningful market value, and break down each portfolio into teams, laying out the following:
- what service the team provides
- which customers the service is provided to
- which capabilities required to provide the service to the customer
- which people provide that capability
- which dependencies each team has on another team
- Add service delivery patterns and team linking patterns to your team model to outline how knowledge workers interact with each other.
- Select a service delivery pattern for each service that the team provides.
- For each cross-team dependency, define the connection using one or more team linking patterns.
Start by describing the services, clients and capabilities of your teams, and organize them into higher-order missions.
- Define a clear, compelling mission statement for each team in the portfolio.
- List the customers for each team.
- Outline the discrete service that each team provides.
- List the capabilities required for each team to be successful, and map them to services (if necessary, specify the people who will be on the team).
- Organize teams into portfolios that have a higher common purpose.
- Lay out dependencies and interactions across teams in and across portfolios.
The first thing you want to do is create a network map of team customers, the services those customers require, and what is required to deliver those services. Grouping services into clusters, and assigning capability and people to deliver those services, will give you an idea of how to form your teams and who should go in them. Depending on the scale of your design, you may start with portfolios and work your way down, or you may start with individual customers and services and work your way up. In practice, I have found that you need to take both a top-down and a bottom-up approach. The goal here is a map that will show you the relationship between customers and the teams required to deliver value to those customers.Below is an example of a channels delivery team within a large financial services organization.
Team patternsAs you start laying out your map, you may want to start introducing one or more agile ecosystem patterns. These patterns fall into two categories: team service delivery patterns, which describe how a team wants to deliver a certain service to a customer, and team linking patterns, which describe how teams can collaborate and share information with each other. These patterns provide a high-level language that allows you to begin defining agreements between teams, customers and other teams. Patterns are applied to the ecosystem map by literally tagging various services and connections across teams with the appropriate pattern.Team service delivery patterns describe how knowledge workers can provide a discrete value to a set of internal or external customers. A different pattern can be assigned to each service.
Team linking patterns describe methods that teams can use to coordinate and collaborate across team and organizational boundaries. Each connection between teams can be annotated with a linking pattern.
Below is a more complete example of a mapped-out agile ecosystem, including supporting patterns. It comes from a from a real use case where a payments IT department wanted to organize its delivery team of approximately 40 people into an integrated agile delivery system. A payments “lab” was stood up, consisting of a discovery team (made up of product owners, subject matter experts and architects) and a set of feature delivery teams. The discovery team did initial backlog shaping and worked with feature delivery teams to determine what work would go on which team backlog. Discovery team members acted as travelling intent owners, moving to the appropriate feature team to act as product owners for the duration of the request. An interesting component of this structure was that developers were dynamically deployed to the appropriate feature team based on analyzing the backlog to understand which systems were being impacted. Engineers were grouped into a number of system-based traveller pools. Each of these traveller pools also had some reserve capacity and a dedicated backlog to manage system-based production defects.
Details, detailsGetting into the details of each pattern—when to use it, the benefits, the trade-offs—will be the subject of a later post. For now, details of each pattern can be found in the agile ecosystem designer’s toolkit here:www.slideshare.net/agilebydesign/agile-teams-services-design
