Skip to main content

Who should facilitate meetings with external traditional teams?

Last post 06:39 pm October 11, 2022 by Anos Nymus
6 replies
02:59 pm October 7, 2022

I work as a SM in a team following self organization principles. 

Unfortunately as we don't live in an ideal world, there is a system, maintained by a traditional team, that provides us data that we depend upon.

That said, from time to time it's required alignment meetings, not only from a business perspective but also technical, from our Scrum Team and that traditional team.

The question is, who should organize those sessions? I'm inclined to say that it should be the scrum team members since they are self-organized, but again, that other team really follows traditional guidelines so developers are not really empowered if they facilitate and participate my themselves, or if the PO or the SM should lead on these cases.


03:08 pm October 7, 2022

Why do you need another alignment meeting? It seems like the "traditional team" that is maintaining the external system is a key stakeholder of the work done by the Scrum Team. Because of that, they should be invited to participate in the Scrum Team's Sprint Review. This would be a good opportunity for the teams to synchronize and align on their next steps.

If you do need additional opportunities for the members of the two teams to get together, what would you expect from a facilitator? Other instances of communication could just be the right people on the Scrum Team talking to members of the other team, but the people involved would vary depend on what was being discussed. Ad-hoc and just-in-time communication can be helpful and may not need much facilitation.


03:25 pm October 7, 2022

developers are not really empowered if they facilitate and participate my themselves

Let's put the alignment meetings to one side for the moment. Can your team make a Sprint commitment, and hold themselves accountable for meeting it, which requires the work that the "traditional" team does?


04:07 pm October 7, 2022

@Thomas, thanks for your suggestion. I'll try to make it work.


04:40 pm October 7, 2022

I wouldn't "try to make it work". I'd start with small changes. You have one event for synchronization between Scrum Teams and key stakeholders outside the team. Take advantage of that and then revisit. Use future Sprint Reviews and Sprint Retrospectives to reassess, perhaps making additional changes if you continue to experience problems.


04:40 pm October 7, 2022

I agree with @Thomas.  You already have a Scrum Event that would allow for the two teams to communicate at the end of each Sprint.  The Product Owner should be including them in the Sprint Reviews.  If I were the Scrum Master, I'd approach the other team and ask if they would be willing to experiment with an alternative.  Educate them on the purpose of the Sprint Review and convince them to try it for 2-3 Sprints.  

@Ian gives you a very different perspective that is a fabulous way of discussing the situation.  Discuss it with your Scrum Team, discuss it with the other team.  Then facilitate a discussion with both teams.  Let the other team see the power of self-organization. It will also help them understand how to effectively interact with the Scrum Team.


05:47 pm October 11, 2022

In your description you seem to be a receiving party for some data (1), or is your team a delivering party to that other party (2), and/or are you both responsible for delivering same dataset to yet another party or parties (3)?

In the first 2 situations there should be an SLA of some kind, which should have something formally described about that regular meeting. PS: mores could also be an SLA of some kind (!).

If there is no SLA, or there is reason to break up the SLA: talk with the head of the other team and find agreement about who does what under which conditions.

In all situations (1, 2 and 3) there should always be clarity about who is responsible for what and when, including a regular meet up/alignment.

Who is actually responsible for arranging that regular meetup is, is more an outcome of what is agreed upon (preferably made explicit in an SLA ), then what is a rule in SCRUM.

Actually when someone has the opportunity to take the lead and in that way have more influence on the outcome, for me that would be a reason to have a preference to be in the lead of arranging and chairmanning such a meeting. But only if it supports what we have to deliver.

If you are responsible for the result, and you are allowed to allocate the FTEs to it, then take the lead!

If the other party is responsible for the result, then let them do it, or let them pay your team to facilitate the meeting.

PS: if situation 3 applies (you are both responsible) and the other team is not prepared to invest the time, it might be a good time to break up the contract, or rethink whether your team wants to be fully responsible for something while only partly (your team) is able to deliver the stuff for the desired quality. One can also lower the guarantee on the quality by the way, but most clients would not allow that.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.