When looking at ways to organize for agility, we often turn to the classic agile team as the "one structure to rule them all". Yet in my experience this is only one of several organizing structures that I have seen. This article provides a description of other ways people can organize to increase collaboration, documented as a set of Collaboration Patterns.
Why are Patterns Important
An intro to Patterns and Pattern Languages
Design Patterns are something I fell in love with almost two decades ago when I was cutting my teeth as an application developer. In the face of a world that teemed with both complexity and complication (remember these two are not the same thing) the discovering patterns was a welcome alternative to standard playbooks, processes, and answers presented as simple recipes that we could copy and paste.
Unfortunately, as we have already discussed, the one size fits all approach to managing our work breaks down in a world of constant market uncertainty. What the other person used to make himself successful can’t be used to make yourself successful, at least not without substantial modification.
Software Developers have known this for a long time. The algorithm, data structure, or object interaction that works for one use case can’t be blindly applied to the next use case. But common reoccurring problems could be solved by solutions that had common attributes. These solutions could be presented in such a way as to discuss some common implementation options. Trade offs and relationships to other solutions could also be presented.
The object oriented community is a place where Pattern Languages first became wide spread, even if it’s not where they were invented. A Pattern is a solution that addresses a known family of problems. Presented with trade offs and relationships to other patterns. A Pattern Language is a map of these patterns and their problems that illustrate how these patterns connect to each other. Patterns allow us to get reuse because we don’t make the fallacy of thinking that a pattern is a fixed solution. Patterns almost never get implemented without some form of modification. Patterns are also meant to be small, you could never implement an entire software solution using only a couple of patterns. You would likely use many of them, and you would use them to solve discrete aspects of your solution.
Patterns for Organizing Structures that Improve Agility
The idea that patterns can also be used to help get better organized came to me when I was reading various texts by Don Reinertsen. Two of his books Managing the Design Factory, and Product Development Flow were instrumental in changing the way I thought about agility and agility at scale. One of the key things Don talks about are process patterns. Most process design work gets it wrong according to Don. Process design often suffers from designers trying to get alignment on top and medium level processes across an organization, one that spans many different contexts. In complex systems this approach doesn’t work. A much sounder approach is to agree on common process patterns, small reusable solutions that are fit for a particular problem space. These process patterns can be connected together as required to build larger processes and organizing solutions. Organizations can develop a pattern maps to help them navigate how to connect these patterns together. Don talks about how standardizing from the bottom, by leveraging common patterns, gives organizational / process designers common components that can be combined into more overarching solutions.
A good metaphors is how children can use a finite set of LEGO building blocks to build a much wider, almost infinite variety of larger creations. Don's writing on patterns caused me to think about the different way I had witnessed people collaborate with each other. There were common approaches shared across official agile methodologies. There were common solutions that people gravitated to. Their were also common anti patterns. By taking a step back and separating the dogma from the practical it became possible to start seeing these common patterns of collaboration.
While I was reading Don's work, I was also getting immersed in David J Anderson's Kanban Method. People often mistake Kanban for just being a visual management system that allows you orchestrate and improve the flow of your work. It is that, but Kanban is also a lot more. Once you reach a certain level of understanding, you will find that Kanban enables people to re-team as required to collaborate on the delivery of value. Kanban enables not only stable, cross functional teams, the most obvious pattern we see in the agile world, but lots of other ways of forming together to collaborate as well. Many of the patterns I discuss here are inspired by my and other's experience using Kanban to enable people to form group that collaborate on value together. In later chapters I'll go into into more details on how Kanban enables the dynamic self organization represented by some of the collaboration patterns presented here.
Collaboration Patterns
Let's get started with what I am calling Collaboration Patterns. Collaboration Patterns discuss different ways people can can engage with each other to create value. They provide advice on the type of help people can provide with each other to collaborate on value. Common attributes like the duration of the collaboration, the nature of the collaboration, and the outcomes are presented.
Collaboration patterns are helpful when you are refining your organizational design and want to layout how different skills and the people that possess them can engage with each other across the various structures in you organizations. They are especially helpful for people who provide support functions from the Core and want to understand their place in an increasingly agile world. It can be tough for core functions to describe more agile ways of collaborating with market facing groups in the Edge, and I have seen these patterns provide a good start in that discussion. These patterns are can used to describe how members of Edge teams can collaborate with each other.
These patterns are:
- Dedicated Team Member - you are a dedicated member of a classic agile team
- Enabler - you are responsible for enabling multiple teams to use an organizational cross cutting capability, by providing guidance, a platform, relationships, and/or knowledge
- Community Of Practice - you are part of a group of people that share passion and knowledge and learning with each other about a certain capability
- Traveler Pool Member - you are part of a pool of people that travel to work closely with teams who have an ad-hoc need for your highly specialized and often difficult to learn capabilities
- Service Provider - you service the need of other people in the organization by fulfilling an order request, largely in isolation from the person making the request.
- Dynamic Team Member - You form into a team temporarily, to achieve a short term goal
- Mission - you align a group of teams, pools and Enablers to a common overarching outcome, sharing a common backlog of work, and/or solution platform.
These patterns, and the different options that these patterns can be used form a Collaboration Pattern Language presented below.
Dedicated Team Member
Summary
You are a full time member of a cross-functional, stable, market facing team (ie Classic Agile Team)
Problem
You are trying to create value in an environment of uncertainty, complexity, and constant change. A mix of skills and capabilities is required to successfully deliver that value. The need for your particular set of skills is significant and it is also stable over time. A high degree of collaboration is required between you and the rest of the team in order to deliver on this value. The actions required to deliver value can be described as being complex, the work is emergent, and requires continuous learning to be performed effectively.
Solution
Collaborate as a Dedicated Team Member of a classic agile team. The classic agile team is typical 6 - 8 people. You and your team members together posses enough cross functional capability to deliver on a market outcome. You will tend to work together by using a variety of agile practices such as working on a small number of small things at a time.
When you choose to be a Dedicated Team Member, you are committing to the fact that you will be spending the majority of your working day with that team in order to achieve the goals of that team. Typically, you will choose to physically co-locate with other members of the team for as much time as you can.
Discussion
Where possible we want most of our Edge teams to be comprised of people who are choosing to be Dedicated Team Members. As mentioned previously we want most of our people in the organization to be part of Edge teams. This implies that most people in our Organization are Dedicated Team Members of Edge Teams. This won't always be possible depending on context, but it is a goal to strive for when trying to maximize agility.
In general, we also want Dedicated Team members to be part of a team that takes responsibility for end-to-end delivery of value, but this is not always possible. In some cases, we may have Dedicated Team members be part of teams that focus on a particular part / phase of value delivery such as discovery, delivery or operations.
Options
The typical 6 - 8 team size is a general guideline. I have seen teams smaller and a good size larger. While agile purists may balk at teams that get much bigger than 8, the reality is that members of larger social groupings can form into smaller groups to work on discrete items in their backlog.
Feature Cells
Feature Cells are a grouping of 2-3 team members who form to work one on discrete increment of value ie a feature or small collection of stories. Team members can choose form into feature cells as a part of the teams planning cadence, and then choose to be part of a different feature cell during the team's next planning cadence.
Dynamic Feature Teams
Some organizations choose to forego stable teams for the most part. Instead members of a larger Mission / Tribe / Portfolio form into teams based on looking at a larger, Epic / Goal level backlog, typically during mission level planning cadence where every member of the mission attends. In this model members of the squad not only self- organize once in a team, they self-form into teams as required to deliver a larger, typically market deploy-able, increment of value. Dynamic feature teams may have some members of the team who are considered stable, they are fixed members of a team based on a particular initiative or platform, while the remaining membership changes dynamically on a more frequent basis.
In the case of both Feature Cells and Dynamic Feature Teams, visual management systems ie Kanban can be used to help inform people on how to dynamically form into groups dedicated to an increment of value.
Traveler Pool Member
Summary
You are part of a pool of people that travel to work closely with members of other teams.
Problem
Other teams, typically Edge team, have an ad-hoc need for your capability. Your skills are highly specialized, and can take a long time to learn and/or required extended training and experience. Demand for your skills can be infrequent, so it’s hard to justify your permanent presence within a specific team. The nature of your work tends to be complex, so when you are working with a team to create value, a high degree of collaboration between the you and other team members is required.
Solution
Organize yourself into a pool of people that exhibit similar capability and also are subject to ad-hoc and complex demand. Allow other teams to draw from you and your peers in the pool on a just-in-time basis. When servicing a request from another team you travel to that team and work in a highly collaboration fashion, in effect becoming a member of that period for a short period of time. At the end of the request you go back into the pool so that you can travel to the next team that needs your assistance.
Discussion
Traveler Pools allow you to minimize hand offs in the face of demand that does not lend itself to stable teams. Imagine a digital channels team that delivers features on a web site that interfaces with a different legacy system for each product being exposed. When delivering digital channel web site changes to the market, there is often a need to make changes to these supporting back end systems. But no two web site changes hit the same back end system across any particular calendar quarter. Now imagine there is a similar mobile channels team, an IVR team, and a call center support channel team, all who have the same type of demand hitting each of these legacy systems.
Organizing people who can make changes to these back end systems into Traveller Pools is a good way to go. Ensuring a feature works end end across multiple systems is a complex endeavor and best performed without hand-offs. Organizing people into pools ensures that the ad-hoc nature of the work does mot cause collaboration to suffer.
Being a member of a Traveler Pool is not always easy and can cause stress for the member of the pool. Maturity is required for a person to be able to switch from team to team and be able to work in an open and collaborative manner. Pools are often fixed to missions, or at most programs, in order to ensure that members of the pool start to become familiar with the people in the teams they are travelling to.
Traveler Pools can use visible backlogs and other agile cadences and practices to prioritize and manage their flow of work.
Options
Dedicated Team Members who also Travel
Dedicated Members of Edge Teams may also act as Travelers to other Edge Teams. This happens when it is not possible for two or more edge teams to completely isolate their work from each other. In the case where teams have dependencies on each other, it makes sense for a dedicated team member to go into traveler mode and work with the other team, rather than expect people across teams to work on a shared piece of work in isolation from each other.
Traveling To Enable
Travellers can also ask members of dedicated team members to pair with them to start picking up their skills. As capabilities sharing starts to happen, the Traveler is able to shift his approach, taking the stance of an Enabler, moving away from doing the work, to guiding someone else on how to do the work.
Service Provider
Summary
You service the need of other people in the organization by fulfilling an order request, largely in isolation from the person making the request.
Problem
You need to fulfill requests from many different teams. Individual work requests tend to be smaller in duration / effort. Your work is expensive to scale, at least compared to the value it brings, ie it is perceived to be a cost center. Your work is considered to be highly repeatable and does not vary greatly from request to request. Economies of scale can be applied to share demand, reduce cost, and increase efficiency.
Solution
Work as a Service Provider, typically in a service center with other similarly skilled service providers*.* As a Service Provider you handle requests for your work using service request / order ticket mechanism. Work travels to you and other Service Providers, you don't travel to teams to collaborate with them to complete the work. You may provide periodic consults to your clients, but the vast amount of your work is completed in isolation. You spend more time with other Service Provider, with outputs delivered once the work is complete.
Discussion
Of all the collaboration patterns presented so far, this one is the one that will lead to the least agility. Every time you are relying on using a Service Provider you are creating a hand off. Hand -offs erode self-organization. They cause loss of context, most service providers don't understand why they are doing something for you. This causes poor results that miss the intention of the person who needs the work completed.
Most back office functions are organized like service centers. They should not be. If you have the pull and political will, help Service Providers to behave more like Travelers or Enablers. At least for the most part, I have seen Service Centers play an effective role in some situations. Activities that require a lot of manual labour / processing may need the economies of scale offered by this model. As software becomes more pervasive, the need for Service Provider diminish.
The Service Provider is really an anti pattern. It is included with other collaboration patterns here because anyone responsible for defining more agile organizing structures needs an means to describe the option we come to when for all intents and purposes it is not possible to negotiate a more agile solution. This allows us to represent the organization as it is, or as it will be for the foreseeable future. not as we want it to be.
Options
Service Provider From the View of the Outside
A team may seem like a service provider from the perspective of the customer of the team, it provides a common service using a request response approach from the perspective of the requester. That team could also appear to be comprised of Dedicated Team Member within a classic agile team when looked at from the perspective of the people doing the work. It is an unfortunate truth that most agile teams housed inside of the IT departments of large enterprise fall into the category. Very few, or even no one, on the team has direct market contact, work comes to them from various outside stakeholder who may or may not offer periodic advice to the team. The user and the customer are far from the team, and while the team may exhibit great internal agility, they exhibit poor market agility. This team can be said to be a Service Provider From the View of the Outside.
Intent Owner Traveller to The Service Provider
One way agile teams mitigate the impact of being engaged like a service provider is try and get stakeholder / sponsors / users to come and spend time with the team to share context, provide feedback, and otherwise bring market connectivity with them. This is a reverse kind of travelling, the person that needs skills / capabilities (ie a team) in order to deliver value travels to the team that can provide those capabilities. This Intent Owner Traveller collaborates closely with the Service Provider Team, in effect this allows the team to operate much closer to principles of an Edge team.
Dependent Edge Teams
When two teams agree to work on a complex piece of work that is shared across teams, and neither decides to pick up and move to work with the other team, than both team are acting like Service Providers to each other. They are now Dependent Edge Teams. Sometimes this can’t be helped, but in most cases we are dealing with social inertia and a mindset that once someone is in a team that is where the work happens, regardless of the rework or confusion it creates. Remember, hand-offs kill agility, don’t be that guy who refuses to travel, and thus creates a hand-off.
Enablers
Summary
You are responsible for enabling multiple teams to use an organizational cross cutting capability, by providing guidance, a platform, relationships, and/or knowledge.
Problem
You posses a set of core foundational capabilities and you want these capabilities to serve as foundational building blocks for as many teams as you possibly can. You want to provide these capabilities in ways that give your organization a strategic advantage in the market, perhaps increasing greater safety, security, or even speed of delivery of value across your teams. You want to provide these capabilities in way that allows teams to spend more time delivering market value, and less time on more “infrastructural” concerns.
Solution
Provide capabilities to teams by collaborating as an Enabler. As an Enabler you are responsible for bringing platforms and knowledge to team members. An important distinction of an Enabler is that you are not responsible for doing the work, you are responsible for helping team members be more effective at doing the work.
Discussion
Enablers often are members of a capability specific Enablement Teams that sits in the Core of the organization. Often members of these Enablement teams are focused one a subset of the organization, like the Jedi Council or the Green Lantern Core (yes I am geek, quelle surprise), an Enabler can be assigned to watch over a closely related set of teams or larger organizational grouping such as a program or mission, helping to bring order to their sector of the galaxy.
Enablers help value-delivering teams be effective in a certain capability, but empower them to operate in a self-service mode. Technology platforms, bodies of knowledge, teaching aides, etc are all tools of trade for enablers.
HR, Legal, Security, DevOps and agile coaching teams are all good examples of enablers, positional leadership can also be thought of as Enablers. One of the biggest challenges with Enablement is that it is confused with authority. In traditional organizations many of the functions listed above maintain coercive power over Edge teams. When using an Enablement pattern, the services of an Enabler are voluntary. We cannot effectively enable others through command and control, it will never lead to a durable change in behaviour. Coaching people who are in enablement functions to approach the way they work from this point of view is no easy task. It required constant focus and reminder.
Options
Enabler who Travels and Provides Services
I know some of you must be wondering WTF is Jeff talking about when he say Enabler who Travels and Provides Services? The reality is that most Enabler Teams do not get the opportunity to act as pure a pure Enabler. Until the organization reaches a certain level of maturity, teams will likely ask Enablers to help in a variety of ways. Sometimes this means operating as more of a Traveller, working closely with teams and pitching it to do the work. Sometimes it may even mean operating more like a Service Provider, and doing some of the work for the team, treating the requester as a client, and presenting a finished deliverable back to requester.
As an example, a team of Agile Coaches should operate as the archetype of an Enablement team. Yet coaches may need to temporarily play the role of Product Owner or Scrum Master if their is a desperate need, they may also be asked to build approach documents or methods collateral from important stakeholders. None of these are what the agile coaches would want to do, their time is better spent coaching leaders and teams. But sometimes what is practical trump what is pure.
On the other hand, the hybrid Enabler who Travels and Provides Services pattern also provides a path for teams that are doing work that they would like requesters to start doing for themselves. Service Provider Teams can start reserving capacity to build up platforms / knowledge to help requester teams self serve take on the work on their own. Travellers can be deployed to customer teams to first do and show, then pair, then advise, and finally step back and allow the team to do the work themselves. Getting agile teams comfortable with using Devops is an excellent example of how an infrastructure team can graduate from a Service Provider team, to Travellers, and then to a team of Enablers by thoughtfully increasing the level of self service that teams can perform through a combination of platform, permission, and coaching.
Communities of practice
Summary
You are part of a group of people that share passion, knowledge, and learning with each other about a certain capability
Problem
You want to to encourage grassroots level learning and shared understanding on a particular topic or capability. You may posses a functional capability that does not really have an organizational home in this new world of cross functional teams. You want an opportunity to volunteer your time to collaborate with others to excel in your and their common craft.
Solution
You participate in a Community Of Practice. When you participate in a CoP, you collaborate to share knowledge amongst your peers. You spend some of your time creating a body of knowledge through consensus, and through sharing knowledge from practitioner experience in the field.
Discusssion
Communities of practice are responsible for stewarding specific capabilities that are important to the overall enterprise. Unlike Enablers, Communities of Practice are often virtual; membership comes from interested contributors on other teams. CoPs may have dedicated funding and/or management. The difference between a community and a more traditional Center of Excellence is that communities do not hire, fire or manage people’s careers. They are not resource centers. A communities mission is to foster a sense of community amongst like minded people. Communities of Practice help people move their craft forward. They hold learning events, tours, outings, etc and activity is driven largely by volunteers.
Options
Enablement Vs Communities
It may be tempting to organize many capabilities as Enablement centers, for instance an Engineering Enablement team and a Product Owner Enablement team, or a UX Enablement team. As we try to increase agility, we want to also allow volunteerism to steer many of these efforts. Consider putting effort behind Communities Of Practice instead. Enablement teams can and should spend time fostering communities, a good sign of progress is when an Enablement team is able to retire, the capability is being fostered effectively through a community instead.
Dynamic Team Member
Summary
These are just-in-time teams with members drawn from a collection of teams.
Problem
You need to collaborate with members from a number of different teams at the same time in order to accomplish a complex task. You do not want to change the existing team structure to collaborate on this task. Perhaps the duration of the request is to short to justify such a change, perhaps their is a lack of will across teams to move people to different teams for an extended duration.
Solution
Form a Dynamic Swat Team with select people from the other teams you need to collaborate with. Often you and other members of the team will agree to participating in one or more agile style sessions, like stand ups, as well as adopt some form of visual management or shared discovery practices.
Discussion
As people become more and more safe, the hard barriers represented by stable agile teams may seem less and less important. Using visual flow / Kanban as a guide, members of different teams may start seeing opportunities to swarm around the work as necessary to maximize flow of value. It is truly a beautiful thing to watch when a group of people spot an impediment or obstacle that can be quickly resolved if they work together for a day/week or two to solve it, outside of their familiar organizing structure. Dynamic teaming is an advanced behaviour that has been observed in a number of places, and will increasingly gain prominence as the need to scale with agility increases. I’ll be providing an entire chapter on how Kanban can be used to enable dynamic teaming.
