Over a million developers have joined DZone.

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

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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?

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:
scrum ,agile ,sprints ,teamwork

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

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

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

{{ parent.tldr }}

{{ parent.urlSource.name }}