A couple of times, I found a particular pattern of interaction from a team with some other group (or team) useful. I would not recommend it all the time, but there appear to be appropriate use cases every now and then. Since I didn’t cross similar thoughts in the Team Topologies book, I thought it useful to write up as inspiration for others. Let me introduce the ambassador to a team.
The first time I saw this kind of interaction at work was a couple of years back at a manufacturer. They used Scrum to build up the first prototype of their new mid-priced product. They were already in the market in the low-, mid-, and high-price market with their product, yet their mid-priced product needed a revamp to keep up with the competition. The product development consisted of prototyping, CAD of the interaction of the different hardware components, some electrical board design, and software development.
As the Scrum Team made more and more early design decisions, they needed to interact with the purchasing department that finalized the contracts of various suppliers, both for the prototyping phase as well as the final mass-manufacturing conditions. Each Sprint the team settled on a combination of decisions, that was explored in the purchasing department by a different department. Usually, contract negotiations with vendors took about six weeks in most cases and included PCBs and raw materials for the construction part.
Since all these different vendors and product raw materials had varying expertise on the purchasing side, there were three to five different people involved from the purchasing department. Depending on which component you were looking to settle a contract, a different person might come into play. Since the work from the purchasing side took six weeks most of the time, it was hard to incorporate into the product development Sprints, yet, there was a high demand for interaction between the Scrum Team and the purchasing department, i.e. to review proposed parts and conditions on candidate contracts before deciding on a particular vendor.
In this company, on this Scrum Team, we worked with a fixed person from the purchasing department. That person would join the Daily Standups, on-demand attending the Sprint Planning, and maybe the Sprint Retrospective. Whenever the team needed something from the purchasing department, they had a go-to person from the purchasing side, that took the Scrum Team’s requests and coordinated with her colleagues from purchasing to fulfill them. Over time, I started to call this person the Scrum Team’s ambassador from the purchasing department.
The Ambassador – a brief description
If a Scrum Team needs to interact with another group of persons often, yet the nature of work of that other group is so distinct from the Scrum Team, it makes sense to have a fixed go-to person that takes care of the necessary coordination for that other group. The other group maybe a group of persons working alongside each other with their own fields of expertise, or another team, I recently found it.
Note, as is the case in politics, the ambassador might have a spectrum of decisions that she can take on her own. The broader the decision spectrum of the ambassador is, the more timely decisions from the other crucial group might get back to the Scrum Team. In that case, the Scrum Team will less often wait for decisions from outside the team.
Another note: the ambassador may bring one member of his group together with the Scrum Team to carry out the coordination work, or do it on his own. I see a parallel to the ambassador in politics there as well. Some negotiations are carried out by the ambassador on her own, others are carried out by her staff, and it’s totally up to how the group of the ambassador is organized on how the coordination happens.
Other uses where an ambassador seemed reasonable
Last year I was involved with a Scrum Team in a similar situation to the above example where this ambassador role came to my mind again. At my current client, I found this role useful in a slightly different setting. The work they do appears to make the most sense to split up into an enabling team and a stream-aligned team in the first phase. Once the enabling team managed to enable a particular functionality in the developing application system, the two teams change their interaction mode to full collaboration in the second phase. During the first phase of the development, while the group is split into an enabling and a stream-aligned part, an ambassador from the other team would be useful to have for both teams.
Overall, I am not sure to which extent the ambassador should be temporary as in the latter example I mentioned, or permanent as in the case of the team in the first chapter. Personally, I would strive to keep it as a temporary construct while we learn forward on how to bridge the limitations that demand two different groups working toward the same goal in parallel. That seemed harder to overcome in the hardware case, and looks possible on my current project, though it might take some time. The ambassador can ease some of the pain for the time being.
Please share some of your own experiences in the comments if you happen to make your experiences with an ambassador.