Team Collaboration Patterns Part 2: The Traveller

The concept of placing people into market facing teams is at the core of Agile Organizational Design. But we won't always be able to get everyone working on the same initiative onto a same team. It we won't always be able place people on teams on a permanent basis. When we try to do this we often end up with massive teams. If we want to support agility at any scale we need to complement the idea of full time team members with other ways people can engage with teams than just the full time, dedicated model.

I use Team Collaboration Patterns as a means to represent these different ways people can can engage and interact with teams. These patterns provide us with options, and I have seen them enrich conversations focused on agreeing on how people can interact with each other within and across teams.

Today. I'll provide an overview of the Traveller Pattern.

Like this article? Download my book on Agile Organizational Design.

Summary

You are part of a pool of people that travel to where the work is to collaborate closely with members of other teams.

Problem

Other teams, typically market facing team, have a need for your capability. But that need is ad-hoc in nature. The team has challenges in simply picking up your skills and expertise by themselves, as your skills are likely highly specialized. Your skillset can take a long time to learn and required extended training, intimate knowledge, and extensive experience to be effective. As a result there are a limited amount of people with in the organization that have your skills set, and it is challenging to increase the number of people that possess this capability.

Demand from any one team for your skills can be infrequent, or at the very least it is inconsistent, so it is 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 Travellers. This pool is made up of all the people that exhibit similar capability. This pool services demand across multiple agile teams, demand that is both ad-hoc and complex. Allow other teams to draw from you and your peers in the pool on a just-in-time basis. Use backologs, throughput planning, and wip limits to prioritize that demand, just like any other agile team would. 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 team 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. One of the biggest mistakes people make when organizing teams is to structure teams based on capabilities, and then allow work to be distributed across multiple teams, relying on cross team coordination in order to create meaningful value. This results in hand offs between teams. We know hand offs reduce a team's ability to self-organize and collectively respond to feedback. Hand offs reduce agility. The alternative option is to use pools of travellers instead, that way we move people to the work, rather than moving work to people.

Imagine we have a web team that delivers features on a web site that touch across a wide range of customer experiences and business products. The website needs to interface with a number of different back end system depending on the touch point and/or the product being exposed. When delivering digital channel website changes to the market, the digital team often need to ensure that a supporting changes is made to one or more of these supporting back end systems. But no two web site changes hit the same back end system across any particular calendar quarter. Most of these back end systems could be considered legacy systems, or at the very least highly proprietary. Making changes to each of these systems is done by a separate group of people, all who who possess very distinct and specialized knowledge from each other as well as your garden day variety object oriented developer.

Now let's scale the problem out to a more realistic enterprise scenario. Imagine we also have a similar mobile channels team, an IVR team, and a call center support channel team. These teams are also responsible for building systems that touch on the same range of products and customer experiences that the web team does, and need to likewise make similar types of changes across the various back end systems that the web team is.

In this case, organizing people who can make changes to these back end systems into separate Traveller pools, one for each system, is a good way to go. Ensuring a feature works end end across multiple systems is a complex endeavor. One that is best performed without handoffs across teams. Organizing people into pools ensures that the ad-hoc nature of the work does not cause collaboration to suffer.

Other good examples where I have seen travelling work well is dedicated UX professionals, customer research and analytics, and larger / program level UAT expertise.

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 a cohesive outcome or other context boundary that groups a small number of agile teams into a common organizational unit. This is done so that travellers within a pool start to become familiar with the people in the teams they are travelling to, along with the mission and outcomes of a finite number of teams.

Traveler Pools can use visible backlogs and other agile cadences and practices to prioritize and manage their flow of work. This includes holding occasional standups, retrospectives, working on technical debt, or other internal improvements.

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.

Like this article? Download my book on Agile Organizational Design.