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 destinationfor tips and interviews with the leaders in the world of Agile. Don’t forget tosubscribe 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 AgilePodcast. Today’s topic will be: Scrum of Scrums. What are they and how do youimplement them successfully? But before we begin – a quick reminder that thispodcast is for informational purposes only and accepts no legal liability. Solet’s get started. As part of the AgileInstructor.com blog and this podcast,All Things Agile, I like to alternate between interviews and informationalcontent. I think it’s important to help listeners with direct, actionableadvice based on hands-on experience. Interviews are great and I certainly lookforward to conducting more interviews, including in the next episode – however,I definitely want to include direct content. Things that I’ve learned from myexperience that I hope can help you.

One of those topics that is often overlooked is Scrum ofScrums. Now, many people have heard of this, but are not really quite sure howto pull it off or perhaps they’re kind of winging it right now and perhapshaven’t seen what has worked at other organizations and are maybe looking forsome 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 companyor at a team that’s focused on a product –that team might work well and be ableto take care of all the needs and that’s great. However, you may have caseswhen one team is just not enough to fulfill the needs of a product. Or perhapsthere are multiple products being worked on and perhaps each team is working onone particular product or component, but those teams then have dependencies oneach other. So just to recap: you may have cases where you have to havemultiple teams working in order to get the job done on a particular productbecause there’s just so much work to do; or perhaps you still have multipleteams, not because multiple teams are required for a particular product orcomponent, but just because maybe there is a dependency between the teams. Youmay have a product A and a product B, and you may have a case where theproducts are supposed to act like a suite. For example, a lot of Apple andMicrosoft products are designed to work together with each other. And so, inthat case, even though the teams may be working on separate products, theystill may have dependencies on each other in which case there are pieces of thepuzzle 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 withdependencies, then there’s definitely the risk that the teams can end upstepping on each other. And, you run into other issues where you need to be ableto 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 getreleased at one time or is going to get delivered to production. And you can’thave those teams so disconnected that they’re causing havoc for each other andmaking it difficult to release the product at one time.

And then you also have quality concerns. You have multipleteams working on products together in parallel – there’s always a risk that oneteam can make a change for something and then inadvertently break another teamand introduce unaccounted for defects. And naturally speaking, that’s not agood thing. So, how to overcome it? Well, there are many different practicesand I’m not going to say there’s any particular right and wrong answer forthis, but one of the more commonly applied principles, or practices I shouldsay, is the Scrum of Scrums.

So there’s a need for it when you have multiple teams and youhave 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 byorganization, 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 seetaking place in many other companies and industries.

Scrum ofScrums is a ceremonial meeting involving representation frommultiple Scrum teams in which those representatives get together and helpsynchronize each other. For example, as I’ve mentioned – usually, what I see in thefield is that it tends to be representation from the contributing or participatingteams. Every organization is different – technically speaking, they couldinvolve all the team members, but what I often see used in the field isrepresentation. Meaning, you have a team of 7 people or so – each teamhas many different team members and if you start to get everybody together, itcan get unwieldy sometimes. So typically, I’ve seen 1-2 representatives perteam.

Again, there’s no hard and fast rule regarding who thoseindividuals are, but what I commonly see is that it tends to be a ScrumMasterand or Product Owner. Now, there can also be cases where another rotating teammember is involved – maybe it’s just a senior technical person or a seniorperson regarding testing, so maybe they rotate on some kind of schedule – but generallyspeaking, I tend to see the ScrumMaster and the Product Owner as being theones that are the most frequent participants.

And if you stop and think about it, that makes a lot ofsense. One of the roles or responsibilities, if you will, that I commonlyassociate with the ScrumMaster is they need to know what the deal is. Theyneed to know how the team is doing. What are the team’s obstacles? What’s theoverall 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 someonewere 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 isalso usually in the loop and should be. The Product Owner should also be aperson who’s actively engaged with the team and knows not only generally howthe team is doing, but also how they’re doing in relation to the scope for theitems that are being worked on for that particular effort or release.

So in this case, having either one or both of thoseindividuals attend on a regular basis is usually what I see in practice. And Ialso see value in having other rotating team members and I think if the ScrumMaster / Product Owner are the only ones to ever attend, then that cansometimes stifle some of the other team members, or maybe sometimes the morale.It is good to have some occasional participation from other team members – itgives them insight into what the other teams are doing and also to ensure greaterparticipation 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 teamsworking on the same product and let’s say each one of those teams provided tworepresenting members – say for example a ScrumMaster and Product Owner – witheach of those teams and members, they’ll usually formed together in some sortof a meeting or, if you prefer the term – ceremony. Basically, a quick meeting.And again, every organization is different, everybody conducts Scrum of Scrumsa little bit differently, but what I tend to see happen in many organizationsis 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 didyou work on yesterday? What are you working on today? What’s in your way? Whatare your impediments?’ Usually, I’ve seen Scrum of Scrums take a little bit ofvariant to that.

So for example, the group members may get together for a Scrumof Scrums and ask questions like ‘What have you worked on since the last timewe met?’ And the reason I mention that ‘since last time we met’ isbecause the frequency for the Scrum of Scrums varies a lot. Some organizationswill 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 thinkthere’s no hard and fast, right or wrong answer on the frequency. I think itreally 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 theproduct pieces being worked on are very complex and there’s lots of teamsparticipating 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 nottoo much risk on what’s being worked on at that time, then a less frequentScrum of Scrums meeting makes perfect sense.

Again – I think that’s totally dependent on yourorganization and your unique situation, but typically what I see is thatmembers get together and they’ll ask ‘What have you worked on since the lasttime we met?’, whatever period that’s been; ‘What are you going to work onbefore 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 workon this week? As an example. And that helps clue in the other members on ‘Didthis team fulfill the items that they said they were going to work on? Did theyaccomplish them; yes or no? And what are they going to work on next, what’scoming up?’ That’s important information to know if you’re trying tosynchronize the teams.

Thirdly, what’s in my way? Or what impediments does my teamhave? Again – just another way of saying ‘these are potential things that canblock us’ or ‘are blocking us’. And part of that reason is to one: see ifsomeone else can help. You may have a case where team A is very blocked at themoment and running into issues, but perhaps someone on team B has had priorexposure 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 thesolution right there and avoid further pain. So it’s a way of not only helpingsynchronize the teams, but also helping the teams help each other. So it’sdefinitely an encouraging aspect of the Scrum of Scrums.

Another facet is by discussing the challenges faced by ateam 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 Ahypothetically – is running into issues, then maybe one or two of those storiesthat have originally been targeted may or may not complete on time and they cansort of mentally put that in their list; if there’s concerns or if there’sdependencies 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 Scrumof Scrums is: What will you put in another team’s way? In this case, I’ve toldyou what has our team worked on since the last time we met? What are we goingto work on or are we working on currently and I have discussed with you arechallenges and impediments, things that are concerning us or blocking us – andforth, here are some items to be aware of, here are some heads-up things. Letme give you some examples of how this can be applied to you. Let’s say you have3 teams working on, as an example, the same product and for example team B isabout to make some risky changes. And they’re going to do it this week and theymay want to ensure that they give the other teams a heads up. Hey – as part ofwhat we’re going to be doing, I just want to make sure you are fully aware thatwe are going to be making these changes, and when we do, it may break some ofthe existing APIs and the other teams present may need to make some adjustmentson 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 otherteams know of your potential impact on them, so they’re not caught off bysurprise and that really helps build trust and you’re not surprising otherteams with problems; you’re letting them know in advance ‘Hey – we’re about toput 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 otherteams 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 thefrequency may vary depending on your circumstances, the representation for theScrum 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? Whathave I worked on or going to work on between now and the next time we meet andwhat’s in the way, what’s blocking me, what’s concerning me?’ And forth ‘Whatdo you need to be worried about? What potential risks can our team inject thatyou 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 ofScrums is not to have a giant, fancy PowerPoint presentation and really sleekgraphics or anything like that. It’s a very, very informal meeting and, in thiscase, 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 isagain going back to the audience. If you have everybody from all the teams, itcan be very difficult to have those sessions in a quick timeframe. That’s whyhaving representation tends to work out better in my opinion.

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

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

So for example, let’s say during the Scrum of Scrums meetingand 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 knowwe’re about to make some API changes and the other two participating teams willneed to make some adjustments for that.’ Great point to let people know aboutit – that’s very awesome. And so when the other ScrumMasters go back to theirteams, maybe for example in their next daily standup, daily Scrum, that ScrumMaster is going to mention ‘Hey, by the way, I just finished participating inour Scrum of Scrums and I want to let you know that team A mentioned in theScrum of Scrums that they’re about to make some API changes and it may breakus, and we may need to make a few changes to adapt to that’.

In this case, the ScrumMaster or the representative, orwhoever it is – they have at least some rough idea, notes or ideas of what wasdiscussed in the Scrum of Scrums. They can relay pertinent information back totheir own teams, so that not only is the representation sort of in the loopwith what’s going on, the whole teams are in the loop. In that case, the teamsthemselves, all the team members are aware of the relevant information forthem. And that way, it’s not just a few people that know what’s going on thereand everybody else is in the dark.

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

Now, in terms of what my experience has been – I think thatone piece of advice I’d issue to you as caution. Do make sure that the Scrum ofScrums does not become a status meeting. Your goal is not to just read off somerandom 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 statusroll call meeting, then the helping each other and the transparencies can breakdown. And so, I would definitely warn or encourage you that when you conductyour Scrum of Scrums, try to keep it focused on ‘Hey, the teams themselves arethe audience. This meeting is for us, this meeting is to help us help eachother, so that we can deliver the products together or within the sameproduct.’

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

The purpose of the Scrum of Scrums is to help the teamsthemselves. I know I kind of beat a dead horse on this one a little bit, butit’s a complicated topic. Many books don’t go into it very much, many websitesdon’t go into it very much either. And there’s not a whole lot of guidance intothe Scrum of Scrums and I just wanted to take a moment and sort of discuss whatis 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 thatsaid, if you are involved with multiple Scrum teams or product or suite ofproducts, I would certainly encourage you to take a look at the Scrum of Scrumspractice if you’re already using it. And if you are using it, I may want toencourage you to take a look at how it’s currently functioning and what thedrivers are, if you will, behind your current meetings. And maybe just take alook at it, kind of like a retrospective. Take a look at how well your Scrum ofScrums meetings are taking place and, you now, as you go, you can always makeimprovements to it.

Alright, I hope you enjoyed this episode! As always, I’mhonored to get a chance to speak to you and stay tuned for our next episodewhere 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 offersuggestions for future topics, please email me. You can reach me at [email protected] and I’llbe happy to include your questions in the next episode. Thank you very much!

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