3

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?

  • Are you looking to reduce duplication of work and make things more efficient? – jmort253 Dec 3 '13 at 20:35
  • Welcome to PMSE. Your question has been lightly edited to make it less of an opinion poll (which would force closure) while hopefully retaining the core of your question. Please feel free to edit further if necessary. – Todd A. Jacobs Dec 3 '13 at 21:14
4

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.

http://www.agileproductdesign.com/presentations/user_story_mapping/

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.

  • I always thought (and was taught) that user stories should not have embedded implementation details, and that those details were task-level? In my past role, we would create a task for those pieces of a story that required external team support, and one of our developers (or even the Scrum Master or BA) would take on that task and take the necessary steps to rope in the needed specialists from separate teams. – JCM Dec 4 '13 at 3:59
  • @JCM The story I used as an admittedly-contrived example describes context and behavior, not internal implementation details. I also recommend that teams cooperate on stories and coordinate tasks between them, rather than assign tasks to one another. --Your question about how to write effective inter-team user stories seems different from the OP's question, and I would encourage you to ask it as a separate question. – Todd A. Jacobs Dec 9 '13 at 13:23
1

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
  • 1
    In general, it is bad form on SE to mmerely reference a link. In order to guard against linkrot, and to persuade people that the link is actually important, it is good form to summarize the content of the link. A couple of bullet points is usually sufficient to allow people to decide whether it is worth following the link. – Mark C. Wallace Mar 21 '14 at 10:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.