Welcome to the All Things Agile Podcast! Your destination
for tips and interviews with the leaders in the world of Agile. Don’t forget to
subscribe to this podcast on iTunes, and please check out our sponsor:
TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.<o:p></o:p>

Ronnie: Hello everyone and welcome to the All Things Agile
Podcast. Today’s topic will be: Scrum of Scrums. What are they and how do you
implement them successfully? But before we begin – a quick reminder that this
podcast is for informational purposes only and accepts no legal liability. So
let’s get started. As part of the AgileInstructor.com blog and this podcast,
All Things Agile, I like to alternate between interviews and informational
content. I think it’s important to help listeners with direct, actionable
advice based on hands-on experience. Interviews are great and I certainly look
forward to conducting more interviews, including in the next episode – however,
I definitely want to include direct content. Things that I’ve learned from my
experience that I hope can help you.<o:p></o:p>

One of those topics that is often overlooked is Scrum of
Scrums. Now, many people have heard of this, but are not really quite sure how
to pull it off or perhaps they’re kind of winging it right now and perhaps
haven’t seen what has worked at other organizations and are maybe looking for
some additional advice. So I’d like to focus today on, again, Scrum of Scrums.
So in this case, let’s start with ‘What is it?’<o:p></o:p>

For those who haven’t heard that term – Scrum of Scrums –
basically, when you have the individual Scrum teams, maybe in a smaller company
or at a team that’s focused on a product –that team might work well and be able
to take care of all the needs and that’s great. However, you may have cases
when one team is just not enough to fulfill the needs of a product. Or perhaps
there are multiple products being worked on and perhaps each team is working on
one particular product or component, but those teams then have dependencies on
each other. So just to recap: you may have cases where you have to have
multiple teams working in order to get the job done on a particular product
because there’s just so much work to do; or perhaps you still have multiple
teams, not because multiple teams are required for a particular product or
component, but just because maybe there is a dependency between the teams. You
may have a product A and a product B, and you may have a case where the
products are supposed to act like a suite. For example, a lot of Apple and
Microsoft products are designed to work together with each other. And so, in
that case, even though the teams may be working on separate products, they
still may have dependencies on each other in which case there are pieces of the
puzzle that still need to align with each other.<o:p></o:p>

With any of our project managers in the listening audience,
they’ll immediately start to think ‘Well, you got to keep these teams in sync’
because if the teams are working on the same product or multiple products with
dependencies, then there’s definitely the risk that the teams can end up
stepping on each other. And, you run into other issues where you need to be able
to release code at the same time together, right? Because if you have, say 3 teams working on the same product, that product is going to get
released at one time or is going to get delivered to production. And you can’t
have those teams so disconnected that they’re causing havoc for each other and
making it difficult to release the product at one time.<o:p></o:p>

And then you also have quality concerns. You have multiple
teams working on products together in parallel – there’s always a risk that one
team can make a change for something and then inadvertently break another team
and introduce unaccounted for defects. And naturally speaking, that’s not a
good thing. So, how to overcome it? Well, there are many different practices
and I’m not going to say there’s any particular right and wrong answer for
this, but one of the more commonly applied principles, or practices I should
say, is the Scrum of Scrums.<o:p></o:p>

So there’s a need for it when you have multiple teams and you
have to keep them in sync, help them ensure they’re not stepping on each other
– what does the Scrum of Scrums actually look like? It can certainly vary by
organization, so I’m going to focus on what do I commonly see in the field?
Again – I’m not talking about a theory or a book, but what I actually see
taking place in many other companies and industries.



Scrum of
Scrums is a ceremonial meeting involving representation from
multiple Scrum teams in which those representatives get together and help
synchronize each other. For example, as I’ve mentioned – usually, what I see in the
field is that it tends to be representation from the contributing or participating
teams. Every organization is different – technically speaking, they could
involve all the team members, but what I often see used in the field is
representation. Meaning, you have a team of 7 people or so – each team
has many different team members and if you start to get everybody together, it
can get unwieldy sometimes. So typically, I’ve seen 1-2 representatives per
team.

<o:p></o:p>

Again, there’s no hard and fast rule regarding who those
individuals are, but what I commonly see is that it tends to be a ScrumMaster
and or Product Owner. Now, there can also be cases where another rotating team
member is involved – maybe it’s just a senior technical person or a senior
person regarding testing, so maybe they rotate on some kind of schedule – but generally
speaking, I tend to see the ScrumMaster and the Product Owner as being the
ones that are the most frequent participants.<o:p></o:p>

And if you stop and think about it, that makes a lot of
sense. One of the roles or responsibilities, if you will, that I commonly
associate with the ScrumMaster is they need to know what the deal is. They
need to know how the team is doing. What are the team’s obstacles? What’s the
overall progress on where they’re at? As I like to call it: the ScrumMaster always knows the pulse of the team at all times. If someone
were to stop the ScrumMaster in the hall and ask how his or her team is doing,
they should be able to answer that question. Conversely, the Product Owner is
also usually in the loop and should be. The Product Owner should also be a
person who’s actively engaged with the team and knows not only generally how
the team is doing, but also how they’re doing in relation to the scope for the
items that are being worked on for that particular effort or release.<o:p></o:p>

So in this case, having either one or both of those
individuals attend on a regular basis is usually what I see in practice. And I
also see value in having other rotating team members and I think if the Scrum
Master / Product Owner are the only ones to ever attend, then that can
sometimes stifle some of the other team members, or maybe sometimes the morale.
It is good to have some occasional participation from other team members – it
gives them insight into what the other teams are doing and also to ensure greater
participation and injection of different viewpoints and ideas.<o:p></o:p>

But again, common things being common, I usually see ScrumMasters and Product Owners as typical representation. So if you had 3 teams
working on the same product and let’s say each one of those teams provided two
representing members – say for example a ScrumMaster and Product Owner – with
each of those teams and members, they’ll usually formed together in some sort
of a meeting or, if you prefer the term – ceremony. Basically, a quick meeting.
And again, every organization is different, everybody conducts Scrum of Scrums
a little bit differently, but what I tend to see happen in many organizations
is that Scrum of Scrums tends to form a modified daily