I have joined a start up company as a PM/ scrum master which had 3 scrum teams with different domain specialty 1-FW/cloud, 2- machine learning, and 3- front end( UX/ UI/ dev/QA) on one backlog. The scrum teams where shaped based on their specialty not cross functionally. Each team has 6 to 9 member means the total of people on these scrum teams are 20. We can't have a one scrum team with 20 people. All these people are working on one product. I have set up the sprint planning with all 20 people together and that solved part of cross dependencies I also set up a product meeting weekly with the leads of each team to review our product milestones. During the sprint teams seem to work separately.
How could I solve this issue? I am thinking about scrum of scrum meeting but it means more and more meeting for teams that are already executing an aggressive schedule. Any suggestion?
-
Are they working from a single backlog, and then integrating? How is the work related between teams?– Todd A. Jacobs ♦Commented Aug 31, 2017 at 0:03
-
1Excuse me, but why can't you have a Scrum team of 20? Is it larger than normal or recommended, but that doesn't mean it's not the logical place to start.– RubberDuckCommented Aug 31, 2017 at 16:12
-
@RubberDuck Communication channels with recommended Scrum team size: 42. Channels with a team of 20 is 380! Even discounting real-life complexity, information theory, and queueing theory, that's at least 89% less efficient even on the face of it.– Todd A. Jacobs ♦Commented Sep 1, 2017 at 22:03
-
Yeah yeah. I get that @CodeGnome. I really do, honest. My point here is that it might be a good idea to make them one big team at first just to break down the silos and create an actual cross functional team. It would be easier to transition to small cross functional teams from the giant cross functional team.– RubberDuckCommented Sep 1, 2017 at 22:30
-
This matrix comparison may be useful: agilescaling.org/ask-matrix.html– Tiago CardosoCommented Sep 4, 2017 at 19:09
3 Answers
It's a big question with a complex answer space. My favorite framework for working in multiple teams is LeSS. Their signature book, Large Scale Scrum, is the best book about Scrum (at any scale) that I've come across.
Basically: cross-functional teams, single product backlog, single Product Owner, separate sprint backlogs, and planning and retrospective at both the single-team and overall level.
-
2
Why do you want to do a single scrum with the three teams together?
Let them do their separate scrums, and afterwards do a scrum of scrums. Each team delegates one (or max 2) people for the scrum of scrums and they can discuss impediments between the teams for example. Do it also daily and it should last only 15 minutes extra
Based on what you said, I'm guessing you all experience at least a few of the following the problems:
- Trouble integrating each team's work on a Sprint basis
- Integration related defects
- Communication lag between Scrum teams
- High work in progress
The first rule of scaling Scrum is try not to scale if you don't have to. If you do start scaling development with Scrum, it's important to perform safe fail experiments. This implies you know how to measure the success or failure of whatever you try. Consider before you begin which behaviors, outcomes, or measures might be affected by whatever you try. I would start with the following:
- Cycle time (Todo -> "Done")(I'm considering "Done" to mean potentially releasable)
- Defects produced by new work
- Scrum team member happiness
- Work dependencies found
- Work dependencies mitigated / eliminated
For more great info on how to manage a system based on evidence, check out Evidence Based Management from Scrum.org as well.
I really like Scrum.org's Nexus exoskeleton for scaling, but LeSS appeals to me as well; both have similar systems but Nexus has a few extra constructs I find useful. Caveat, I have been a Professional Scrum Trainer with Scrum.org.
The advantage with Nexus is the concept of a Nexus integration team which is responsible for ensuring a potentially releasable increment of the Product is fully integrated each Sprint. That said, there are some really great tools and practices you can read about in the LeSS handbook.
