In my previous post on designing the agile ecosystem, I covered patterns that can be used to start defining agreements for how teams can deliver within a larger context. In that post, I discussed how team service delivery patterns describe how a team wants to deliver a service to a customer. In many cases, teams will use multiple team patterns, as each service may be provided using a different pattern.
The team service delivery patterns are as follows:Value centres
A value centre is your classic, self-organizing, cross-functional, customer-facing team. Members of the value centre are (ideally) stable and co-located. The focus of a customer value centre is to, well, create customer value.We want to maximize the use of value centres to deliver value. Specifically, value centres make the most sense when demand can be serviced by forming a stable combination of capabilities into a cohesive team, when a high degree of collaboration is required to service that demand, and when the output of the team can be consumed by the market.In general, we want value centres to be responsible for end-to-end value delivery, but this is not always possible. In some cases, we may have value centres that focus on one of these: discovery, delivery or operations.
Traveller poolsTraveller pools are specialized workers that are in high demand across a number of value centres. This demand can be ad hoc, but when needed, these workers are critical to creating value. These workers are often organized into pools, allowing cross-functional or specialist teams to draw from them on a just-in-time basis, typically for the duration of the request. UX, middleware, and legacy developers are often deployed as traveller pools.Organizing workers into traveller pools makes the most sense when there is a scarce set of highly specialized skills that are hard to transfer and take a lot of time to learn. Demand for these skills is infrequent, so it’s hard to justify the permanent presence of the specialist within the value centre. That said, when a specialist from a traveller pool is required, there tends to be a high degree of collaboration between the specialist and the rest of the team within the value centre.
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 upstream value centres or other service centres. For this reason, work travels to a service centre to be processed by the team, with outputs delivered to the client value centre. We can think about old-school infrastructure and process operational teams as being deployed as a service centre.If your model has too many service centres, you will have too many handoffs. In general, minimize the reliance on service centres. Use them when a particular service will benefit from workers having a high degree of internal alignment within the service. Also, service centres are used to perform work that is manual and effort-intensive, and benefits less from market feedback.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.Enablers embody the agile approach to oversight and guidance. They empower other teams—they don’t try to do the work for them. They teach others how to adopt new capabilities, and enable teams to use common platforms and methods.Communities of practice
Communities of practice are responsible for stewarding specific capabilities that are important to the overall enterprise. Unlike enablers, communities of practice are typically virtual; membership comes from interested contributors on other teams. Communities of practice share knowledge, but this knowledge comes from people in the field, not from the community of practice itself. Communities of practice focus on creating a body of knowledge through consensus, sharing knowledge from practitioner experience in the field.Use communities of practice to encourage grassroots development of a shared understanding and learning on a particular topic. Communities of practice are also a good home for various functional competencies, as these tend to no longer be integrated into the value-delivery structure of the organization. Communities of practice provide opportunities for individuals to volunteer in a way that excels their craft.SWAT teams
These are just-in-time teams with members drawn from a collection of teams. They are often used when teams are collaborating together on larger programs or highly integrated functionality, but the original team structure needs to remain in place. The most common instance where a SWAT team is used is when the duration of the work is not long enough to justify reconfiguring the teams. Individuals from different teams need to collaborate together on a highly integrated objective for a brief period of time. There may also be insufficient buy-in to form more stable teams to handle a specific objective; in this case, forming a SWAT team may be a precursor to forming a more stable team.Portfolios
It makes sense to group interrelated agile teams into a common portfolio. Think of a portfolio as a large-scale customer-value engine that provides a market offering. Portfolios tend to leverage an integrated backlog and have dedicated management, along with portfolio-level ceremonies to coordinate work.Use portfolios for the structure and coordination necessary to deliver value at scale. Portfolios help align teams toward a common goal, and contain dependencies within a manageable group of teams.For more info, have a full look at the agile ecosystem toolkit.
