Communicating between agile project teams and shared services

Question

My organization has several teams that are all attempting to use Scrum. Some of the teams are tied to a project, e.g. implement a new web site. Some other teams are shared services, e.g. search engine, networking, DBA. The problem we are experiencing is that the project teams drive requirements for the shared service teams, but communication of the requirements leave a lot to be desired. We have had instances where the Project team has implemented libraries that replicate what the shared service team created a year ago or the project team requests a service very late in the release cycle.

How can our organization improve communications between the project teams and the shared-services teams?

Answer 1

Create Shared Understanding and Big Pictures Visuals

First, don't panic, agile or not, this is an issue with any delivery that requires coordination.

What you want to look for is tools that help create shared understanding and that help people discuss the big picture. While user stories are helpful, they can still be limiting. I would suggest that you map out your product using a Story or Journey Map. These maps act as a visual narrative that captures how a product team believes an overall user experience will play out and then it can be explored with teams and broken down to discover how teams will coordinate it.

Here is a link to Jeff Patton's site to learn more. I recommend downloading his powerpoint presentation that walks you through the process to help you give it a try. It will help you avoid creating a map of features.

https://www.jpattonassociates.com/storymappingslides/

Answer 2

TL;DR

[C]ommunication of the requirements leave a lot to be desired.

This is both the core of your problem and your route to process improvement. It seems likely that you are missing Product Owners and Product Backlogs for each team, and do not have adequate coordination at the Scrum-of-Scrums level.

In addition to filling any missing roles and generating the necessary Scrum artifacts, your organization can leverage user stories to improve your inter-team communication.

Improving Inter-Team Communication with User Stories

Even without the right roles and artifacts to coordinate the teams, you can improve your processes significantly by ensuring that you aren't tossing "requirements" over the wall between teams. Instead, teams should trade user stories that can be used to facilitate direct communications between members of each team.

For example, if a project team building a new web site needs database services, there might be a user story that says:

As a web site user,
I need the database to return the size of my embiggened widget in cubits
so that I can place an order for a widget cozy.

This story is then shared with the database team, which the DBA Product Owner can place onto the database team's Product Backlog and prioritize in coordination with the web team's Product Owner. That's the ideal you should strive for.

Failing that, the user story still works as a starting point for conversations between members of the web team and the database team. It's not a complete specification, nor is it intended to be. It's a mechanism for providing context between the teams, so that both teams have a common frame of reference as they hammer out the implementation details.

Answer 3

In my daily work I used to deal with issue of distributed agile teams and communication within / between teams. I've recently depicted a few (in my opinion) useful hints. Details you find in the post.

This article wraps up several improvements in communication which were introduced in one of the big project I've been working on. To give you a bit of context - it is about collaboration in offshoring model were teams are located in different European countries.

In the post I'm suggesting to introduce following betterments:

• don't afraid to visit customer and work onshore
• get all stakeholders familiar with process
• regular feedback about processes
• daily and weekly meetings rhythm
• proficient communication roles
• clear guidelines on how to build backlog (user stories, stories maps etc.)
• the Product Owner Proxy institution - set it up internally on your side
• robust project tracking tool used for exchanges between the team members

Answer 4

Reorganize into feature teams

You can avoid these communication issues by reorganizing into feature teams. Here are two good references:

• Moving away from component teams is a difficult but necessary step for those who want to adopt an agile project management approach.
• Without a feature team structure (but instead, a component team organization...) your organization is likely to create numerous wastes and sub-optimizations that lead to a sequential (waterfall, ...) development cycle.

If that is not at all possible, setup Scrum-of-Scrum meetings as suggested by @CodeGnome. More on that here:

• Although it's not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting. With this approach, each Scrum team proceeds as normal, but each team identifies one person who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams. These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day. In many organizations, having a Scrum of Scrums meeting two or three times a week is sufficient.

Answer 5

Reading your original post, I notice that you said "the product teams built libraries that duplicated ... what the shared-services teams had done a year ago." It's very important in the case of shared services that everyone can readily see exactly what shared services are available, and exactly what they provide or will provide.