3 scrum team interactions: rules and boundaries
IT teams cooperate intuitively. But the longer they do it, the more some engineers can overstep team boundaries. Here’s how to keep interactions effective.
This is “Effective Delivery” — a bi-weekly newsletter from The Software House about improving software delivery through smarter IT team organization.
It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.
TL;DR
Managers should understand and respect the 3 basic interaction modes set by Team Topologies to prevent chaos,
Each mode has boundaries that can't be crossed
Choose Collaboration for delivery speed, X-as-a-Service to support many teams, and Facilitating for upskilling
Success metrics must change based on the interaction mode
Contents
1. Why respecting interaction modes matters
Hey there! Adam reporting for duty.
Scrum actively discourages cooperation between IT teams.
Teams will also aim to avoid it.
But, inevitably, IT teams get co-dependent, and a PO or EM has to untangle them.
For instance, when an overbloated system needs to be split into modules, multiple teams with different pieces might start blocking each other.
Team Topologies defines 3 interaction modes with strict rules to combat cross-team dependencies.
You can match them to your business goals.
Collaboration mode works for fast delivery of features.
X-as-a-Service mode allows 1 squad to speed up the delivery of other teams.
Facilitating mode is for upskilling feature teams without building for them.
I’m 99% sure the team’s direct manager will set the interaction mode.
Still, I’ve seen too many managers making dubious decisions 😁
So, for the sake of your teams’ success, here’s how to use these interaction modes properly.
Why respecting interaction modes matters
I’ve seen IT teams drowning in requests too often.
And it looked like this:
A stream-aligned team expected immediate API changes from a platform team that served 2 other teams,
3 different teams tried to collaborate closely with 1 DevOps team at the same time,
An enabling team got stuck inside a feature team because people didn’t engage in learning enough.
Chaos! I don’t like to see it. Unless it’s an anime fight.
The three interaction modes force everyone to choose which task/request is a priority.
So, while teams don’t need a paper contract, knowing how a given interaction works prevents many delays.
Regardless of the mode, 2 golden rules apply:
1. No collaboration can last forever
There’s a start and end date. No discussion.
A feature team might want to snatch an architect and keep them as a new ace.
Unless you’re reorganizing a team, don’t let this slide.
2. A feature team can collaborate with just 1 feature team
It’s because both teams use up all of their cognitive capacity on the interaction.
Don’t mix in another stream-aligned team. Why?
One team needs 40 hours weekly to help another feature team reach maximum delivery speed.
Note that a support team interacting in the X-as-a-Service or Facilitating mode can actually collaborate with multiple feature teams.
The 3 interaction modes
Collaboration
It’s the most basic teamwork with transparent and near-immediate communication.
You discover solutions quickly thanks to shared dailies and no handoff delay.
Both teams will hope their bug tickets or data requests get solved on short notice.
Limitations
Team velocity drops when you have meetings with 10 to 14 people instead of just 5.
The information exchange is just overwhelming.
That’s also why collaborations aren’t really sustainable.
Expectations
Group members must be considerate, open to discussions, and available on notice.
Team members might get tense if they keep waiting for their peers to respond.
We worked as a feature team for a hotel booking platform.
We used to submit tickets for an API to the internal complex subsystem team.
Then, new orders came in with a tight deadline.
We convinced the PO to rent us 2 engineers from the in-house team.
Our interaction switched from X-as-a-Service to Collaboration to avoid delivery delays.
X-as-a-Service
90% of Scrum teams work in this mode.
It’s when a feature team takes ownership of a box of services developed for another frontline team.
They need to keep everything in that box running and aren’t concerned with other responsibilities.
Limitations
New service requests get queued and must be planned.
The tempo for delivering new capabilities is way slower.
Sometimes, the API you need now doesn't exist yet, or the service quality is subpar.
One client of ours works with 4 stream-aligned teams from our side.
Each team owns 1 application.
All of them rely on modules built by a stream-aligned team under the X-as-a-Service mode:
payment modules,
survey systems,
and verification components.
The client’s feature teams use ready-made solutions to avoid weeks of grunt work.
Expectations
The service team should focus on the highest DX and UX of the components they produce.
If working with their API isn’t a pleasure, the collaboration won’t be effective.
The feature team might need some convincing to get back in the queue 😄
If the service team takes in an urgent request, it will set a bad precedent.
Facilitating
An enabling team helps feature teams become self-sufficient.
The teachers within it first master a domain like AI chatbots in an R&D project.
Then, they transfer their know-how to a feature team — but never build for them.
This eliminates the “bus factor”.
Limitations
You need your biggest geniuses in an enabling team.
Often, IT managers are unwilling to reassign them.
It's also the least used interaction mode, as most companies don't even know it exists.
Expectations
The teacher should remain present to hop into a task an engineer struggles with.
But the weight is on the members of the feature team as well.
They must have the will to learn, or the interaction won’t work out.
Your feature team might also try to rope in the enabler because of their 007 skills.
Collaboration doesn’t have to take place between complete teams only.
Often, you can create a commando squad of 1 for facilitation.
And platform team might just need 2 people
So, sometimes, you can “borrow” engineers from the feature team.
Measuring success
The real challenge isn't choosing a mode.
It's recognizing when your current mode isn't working.
Here’s what to look out for.
Collaboration metrics
Cycle time and lead time improvements,
Time to market for the specific feature,
Speed of solution discovery.
If you're collaborating but delivery isn't faster, you're doing it wrong.
X-as-a-Service metrics
User experience of consuming teams,
API reliability and performance,
Number of teams effectively served.
The focus is on being a good service provider and not on speed.
Facilitating metrics
Number of dependencies eliminated,
Time until the enabling team exits.
The team being taught must take ownership of a new activity.
Either they do or don’t.
Metrics won’t help much here.
Next time
You’ll hear about engineering obsessions that actually hurt your team's performance.
Like the honorary act of reaching 100% test coverage 😏
Thanks for reading today.
May you have patience for other humans 🙏
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|