All Things Agile - Episode 009 - Scrum of Scrums

Welcome to another great episode of All Things Agile. This blog and podcast is dedicated not only to interviews with Agile leaders but also to actionable and practical advice. In this episode, we tackle Scrum of Scrums. Well cover what it is, mechanics, benefits, and things to watch out for. If you have multiple Agile teams, this is an episode you must checkout.



As always, please take a moment to subscribe using this link: iTunes. Reviews on iTunes are also always appreciated. Do you have a question that you would like answered in an upcoming podcast, please send your question to: [email protected].



All Things Agile - Episode 009 - Scrum of Scrums



Transcript:

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.

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.

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?’

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.

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.

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.

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.

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.

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.

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.

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 Scrum or daily Standup.
Meaning that in your daily Scrum, you might usually have the typical ‘What did
you work on yesterday? What are you working on today? What’s in your way? What
are your impediments?’ Usually, I’ve seen Scrum of Scrums take a little bit of
variant to that.



So for example, the group members may get together for a Scrum
of Scrums and ask questions like ‘What have you worked on since the last time
we met?’ And the reason I mention that ‘since last time we met’ is
because the frequency for the Scrum of Scrums varies a lot. Some organizations
will have Scrum of Scrums weekly, maybe every two weeks – maybe once a sprint.
And some organizations will even have the Scrum of Scrums daily. And I think
there’s no hard and fast, right or wrong answer on the frequency. I think it
really depends also on the nature of the project being worked on and the teams,
and their maturity and the risk level involved. If there’s high risk and the
product pieces being worked on are very complex and there’s lots of teams
participating in this, then having a higher frequency is usually a good thing.
But if it’s a very mature product and the teams are very mature and there’s not
too much risk on what’s being worked on at that time, then a less frequent
Scrum of Scrums meeting makes perfect sense.

Again – I think that’s totally dependent on your
organization and your unique situation, but typically what I see is that
members get together and they’ll ask ‘What have you worked on since the last
time we met?’, whatever period that’s been; ‘What are you going to work on
before the next time we meet again?’ So for example if your Scrum of Scrums is,
say, weekly – What did you work on in last week and what are you going to work
on this week? As an example. And that helps clue in the other members on ‘Did
this team fulfill the items that they said they were going to work on? Did they
accomplish them; yes or no? And what are they going to work on next, what’s
coming up?’ That’s important information to know if you’re trying to
synchronize the teams.

Thirdly, what’s in my way? Or what impediments does my team
have? Again – just another way of saying ‘these are potential things that can
block us’ or ‘are blocking us’. And part of that reason is to one: see if
someone else can help. You may have a case where team A is very blocked at the
moment and running into issues, but perhaps someone on team B has had prior
exposure to this type of problem and they can answer that question like ‘Hey –
I’ve seen that before! Here’s what you need to do!’ and they can give you the
solution right there and avoid further pain. So it’s a way of not only helping
synchronize the teams, but also helping the teams help each other. So it’s
definitely an encouraging aspect of the Scrum of Scrums.

Another facet is by discussing the challenges faced by a
team is that it allows other teams to know that information and account for it.
For example, if they know that one of the other teams – say team A
hypothetically – is running into issues, then maybe one or two of those stories
that have originally been targeted may or may not complete on time and they can
sort of mentally put that in their list; if there’s concerns or if there’s
dependencies where if team A starts to slip behind the schedule, then team B,
which may have a dependency on team A, can then account for it. Like ‘Okay,
well, maybe we need to push off some of our items into a future sprint for example.

I would say the fourth question that can be asked in a Scrum
of Scrums is: What will you put in another team’s way? In this case, I’ve told
you what has our team worked on since the last time we met? What are we going
to work on or are we working on currently and I have discussed with you are
challenges and impediments, things that are concerning us or blocking us – and
forth, here are some items to be aware of, here are some heads-up things. Let
me give you some examples of how this can be applied to you. Let’s say you have
3 teams working on, as an example, the same product and for example team B is
about to make some risky changes. And they’re going to do it this week and they
may want to ensure that they give the other teams a heads up. Hey – as part of
what we’re going to be doing, I just want to make sure you are fully aware that
we are going to be making these changes, and when we do, it may break some of
the existing APIs and the other teams present may need to make some adjustments
on their side, so that they can account for the API changes, for example.

It’s a great way to ensure that you are letting the other
teams know of your potential impact on them, so they’re not caught off by
surprise and that really helps build trust and you’re not surprising other
teams with problems; you’re letting them know in advance ‘Hey – we’re about to
put something in your way, perhaps’. And maybe it doesn’t turn out that way,
maybe it’s just a potential risk – but you just want to ensure that the other
teams have that curtesy heads-up.

So again, just to recap: every organization is different,
every unique industry has its risk tolerance and things like that, so the
frequency may vary depending on your circumstances, the representation for the
Scrum of Scrums can definitely vary – depending on what you organization needs,
but as I’ve mentioned, typically I see in the field one to two representatives,
typically a ScrumMaster and Product Owner, maybe a rotating team member;
typically I see the modified form of daily Scrum or standup. Usually I see,
especially the first 3 ‘What have I worked on since the last time we met? What
have I worked on or going to work on between now and the next time we meet and
what’s in the way, what’s blocking me, what’s concerning me?’ And forth ‘What
do you need to be worried about? What potential risks can our team inject that
you need to be aware of?’

In terms of how much time it takes, what I typically see –
similar to a standup, the process should not take long. The point of Scrum of
Scrums is not to have a giant, fancy PowerPoint presentation and really sleek
graphics or anything like that. It’s a very, very informal meeting and, in this
case, I would say 15 minutes. Similar to a normal, Daily Scrum. It’s, to me,
what a well-oiled Scrum of Scrums should be like. Very quick, very informal,
very direct, to the point. In terms of how to help do that, one of the ways is
again going back to the audience. If you have everybody from all the teams, it
can be very difficult to have those sessions in a quick timeframe. That’s why
having representation tends to work out better in my opinion.

Also, the people participating – in this case, the representation
is from the teams themselves. It’s not really trying to loop end on the project
managers and resource managers and the directors and the VPs and everybody and
their brother. Because the more, honestly, those people get involved in the
situation, the longer the meetings are going to be and the more off-topic they
will be. And that goes back to ‘What’s the benefit to even doing all the Scrum
of Scrums stuff?’ Why should you care?

Well, one is, it helps reduce risk, but more importantly, it
helps the teams help each other. Like I’ve mentioned before, teams can offer
advice to each other. It’ll keep them synchronized as well and it’s really to
benefit the teams themselves. It’s not meant to make project managers happy or
to make VPs happy. And so, in that case, by keeping the audience to the
actionable members of the team, you’re able to operate more informally, more
efficient and sort of get in there, and talk together and be adjourned and move
on with your day. No need to inject a lot of long-winded discussions or
politics involved. Some of the other key aspects of the Scrum of Scrums is that
when you do have the sessions, I think it’s important for someone to maybe take
a few notes sometimes. I’m not saying big, detailed meeting minutes, but it can
be helpful if someone is at least taking some notes regarding that. Typically,
what I see, is that the ScrumsMasters, if they’re participating, they’ll
sometimes take down a little bit of notes – again, nothing formal, on the
conversation that was had. And the reason that I mention that is because when
the representatives leave that Scrum of Scrums, I personally found that it’s
very beneficial for them to relate important notes back to their teams.

So for example, let’s say during the Scrum of Scrums meeting
and let’s say there are 3 teams participating in the product release. They may,
for example, one team A may say ‘Hey, by the way, I just want to let you know
we’re about to make some API changes and the other two participating teams will
need to make some adjustments for that.’ Great point to let people know about
it – that’s very awesome. And so when the other ScrumMasters go back to their
teams, maybe for example in their next daily standup, daily Scrum, that ScrumMaster is going to mention ‘Hey, by the way, I just finished participating in
our Scrum of Scrums and I want to let you know that team A mentioned in the
Scrum of Scrums that they’re about to make some API changes and it may break
us, and we may need to make a few changes to adapt to that’.

In this case, the ScrumMaster or the representative, or
whoever it is – they have at least some rough idea, notes or ideas of what was
discussed in the Scrum of Scrums. They can relay pertinent information back to
their own teams, so that not only is the representation sort of in the loop
with what’s going on, the whole teams are in the loop. In that case, the teams
themselves, all the team members are aware of the relevant information for
them. And that way, it’s not just a few people that know what’s going on there
and everybody else is in the dark.

If you have representation in a meeting, as part of that
representation’s responsibility is to ensure that the other team members that
did not attend are aware of important information. And so, I think that’s sort
of the general gist of the ‘how’, if you will, the mechanics of the Scrum of
Scrums. Again, there’s no particular right or wrong answer to doing that. Every
organization is different, you have to find out what works for you – that’s
kind of the beauty of Agile, to adapt.

Now, in terms of what my experience has been – I think that
one piece of advice I’d issue to you as caution. Do make sure that the Scrum of
Scrums does not become a status meeting. Your goal is not to just read off some
random set of status updates. One of your goals, again, is to help each other.
And to keep each other informed. And so, when you engage in just a pure status
roll call meeting, then the helping each other and the transparencies can break
down. And so, I would definitely warn or encourage you that when you conduct
your Scrum of Scrums, try to keep it focused on ‘Hey, the teams themselves are
the audience. This meeting is for us, this meeting is to help us help each
other, so that we can deliver the products together or within the same
product.’

So if you keep that mentality or focus, then I think it
helps the tone and the attitude of the meeting. Cause if it turns into just a
giant project management status meeting, then I think the morale tends to go
south and helping each other tends to go down as well. Because people are
trying to ensure that they are publicly postured well, that their team is not
looked upon in a negative light. So they may even play down information, they
may even withhold information. They may not want to admit that ‘hey, we just
dropped the ball!’ But if it’s very informal and kept to the participating
teams and focused on helping each other, the teams will have that confidence
and have more candor and transparency, where they can say: Hey, look – this is
really in our way right now and this is causing us major problems. And by being
able to communicate in an open manner, that helps the teams that are
participating feel connected and willing to reach out to each other and help
one another.

The purpose of the Scrum of Scrums is to help the teams
themselves. I know I kind of beat a dead horse on this one a little bit, but
it’s a complicated topic. Many books don’t go into it very much, many websites
don’t go into it very much either. And there’s not a whole lot of guidance into
the Scrum of Scrums and I just wanted to take a moment and sort of discuss what
is it, who’s the audience, what are the mechanics, and what are the benefits –
we talked about that, in terms of the improved synchronization, communication,
helping each other, letting people know about risk, etc. And so, with that
said, if you are involved with multiple Scrum teams or product or suite of
products, I would certainly encourage you to take a look at the Scrum of Scrums
practice if you’re already using it. And if you are using it, I may want to
encourage you to take a look at how it’s currently functioning and what the
drivers are, if you will, behind your current meetings. And maybe just take a
look at it, kind of like a retrospective. Take a look at how well your Scrum of
Scrums meetings are taking place and, you now, as you go, you can always make
improvements to it.

Alright, I hope you enjoyed this episode! As always, I’m
honored to get a chance to speak to you and stay tuned for our next episode
where we’ll be having a special guest interview – I’m really excited! Alright,
well thank you very much and if you have any questions or would like to offer
suggestions for future topics, please email me. You can reach me at [email protected] and I’ll
be happy to include your questions in the next episode. Thank you very much!

Thank you for listening to
All Things Agile. We look forward to you subscribing to the podcast on iTunes
and leaving a kind review. Thanks and God bless!