-
All Things Agile - Episode 009 - Scrum of Scrums
- 2014/10/18
- 再生時間： 1分未満
- ポッドキャスト
-
サマリー
あらすじ・解説
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: coach@agileinstructor.com. 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 ...