Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Cross-Team Cooperation Between Multiple Scrum Teams

DZone's Guide to

Cross-Team Cooperation Between Multiple Scrum Teams

Read on to learn three three possible options for cross-team cooperation based on an engineering lead's real-life experiences.

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

With more and more companies adapting to Agile environments, sooner or later the PO or the lead of the team(s) will experience issues when working on tickets that require efforts from other teams.

These issues may come from many different angles. Some may pop up because the Sprint planning from the other team is different with your own so it's hard to match up the timing; sometimes different teams have different priorities and what is marked as important on your board is pushed to the bottom of the backlog; the worst of them all is that the other team is using a completely different Agile methodology (for instance, your team might be running bi-weekly Sprints while the other team is running in Kanban mode).

Before you read on, I have to warn you that I don't have a perfect answer, so if you are trying to find the holy grail or the remedy, please close the tab and look away! However, I do want to use a few real-life examples (some are from my own experience, some are from others) to explore a bit and, hopefully, we'll find a way that'll work for us.

The "My ticket on Your Board" Way

In one of the companies I worked with, we had three teams looking after three platforms and rarely we needed to implement something that required resources from all the teams. However, eventually, it happened. We were required to push out a feature that involved both the frontend team and the backend team, with a little bit of the account team. 

The first phase (out of four) didn't go well. We were working in the silo of our own team (the front-end team) and only when dependencies were imminent did we turn to the back-end team and ask for help. You probably would have guessed the outcome already: yep, it didn't go well. It was rejected by them, as they were under pressure from the business owners over other features, too.

I quickly grabbed the lead from the other team and called for a little gather up with POs of both teams as well. We then decided to try something very simple but required a bit of discipline. We would create a ticket for the other team on dependencies of the feature and we would invite one of the members of the other team to sit in the Sprint planning. We also stood in each other's Scrum meeting in the morning. 

It actually worked out pretty nicely and we ended up delivering the feature on time and did a joint showcase. Everybody was happy.

The "You Are on My Team Now" Way

In another company where I was also leading the frontend team, we had a similar situation. We needed to deliver something that required effort from the back-end team and I suggested creating tickets and standing in other team's Scrum, only to find out later they really didn't have a proper Scrum or Sprint structure setup. They were doing Waterfall mostly, and it was quite a bit of trouble for us because they didn't really have a board that reflected the progress, nor did they honor the Sprints or planning. The ticket I created ended up in the bottom of the backlog and the morning Scrum was mostly a formality.

We then tried something interesting: we actually asked the person who would be working on our feature to virtually sit with us. He would come to our Scrum, plan with tickets sitting in our board, and report to our PO. Interestingly, this actually worked and we delivered. However, he was stressed out, as he was also required for other duties from his own team, so we really can't say this is a perfect solution.

The "1 + 1 = 3" Way

This is actually an experiment rather than anything else. After the previous approach, we wanted to solve the issue and ensure that no one was burning out, so we planned to trial on building feature teams. Thus, we would have some members from one team and some from the other and they would then together form a third team, concentrating on the feature only, and would dismiss after the feature is done. We are still in the discovery phase of this approach as it requires a lot of overhead and we are not sure if this will work with limited testing resources and POs.

So here you go, the three possible options for cross-team cooperation. Which way do you prefer? Have you tried anything different?

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:
scrum ,agile ,sprints ,teamwork

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}