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!