I have gotten a few questions lately that go about like this:
Still, the Scrum community has dealt with this problem many times. So, here is what Jeff Sutherland and Ken Schwaber and lots of others think are some good ideas to start with.
Let's assume you are talking about putting 3 teams together to work on one project. To release roughly every 4 months. Let's assume each team is about 7 people, including the PO and the SM.
Let's also assume that we continue to focus on Team success. Meaning: We realize that the core of activity is inside the Team. If each Team is not 'working', then no amount of scaling is going to help.
So, the Team's are real teams. Each person is 100% dedicated to one Team.
1. Chief Product Owner. Each team has a product owner, and, in addition, there is a Chief Product Owner -- who manages the Master Product Backlog for all 3 teams. So, the CPO is not dedicated to one Team, but to all 3 teams.
2. Product Owner group. The CPO and the 3 POs all work together. They meet daily, in a separate 'daily stand-up' (brief, 15-minutes) meeting. To be sure things are coordinated from the business side across all 3 teams.
3. Scrum of Scrums. SoS. This means a Daily Scrum across all 3 teams. Specifically, each Team does the usual Daily Scrum. Then, at least one person from each of the 3 teams comes to the Daily 'Scrum of Scrums'. The questions are: (a) what did your teams get done yesterday, (b) what will your team get done today, and (c) what is your team's biggest impediment. A Scrum of Scrums Master facilitates this meeting. And addresses the impediments.
4. Scrum of Scrums Master. There are few rules as to who this should be. It could be a manager who is not on any Team. It could be one of the ScrumMasters on one of the Teams. Etc. But this person becomes the 'impediment-remover-in-chief' for the impediments identified in the SoS.
5. Technical Issues. The main work of the SoS is to remove technical impediments. If a business side impediment is high, that probably would be given to the Product Owner group to address.
6. Continuous Integration. To have scaling across 3 teams, it quickly becomes very important to have much better CI (continuous integration). This is true with just Scrum for one team. But becomes extremely urgent with scaling with 3 teams. Because they are all playing in the same code base.
7. Attendees at the SoS. The initial idea is that the SMs from each team would form the SoS. This works fine some times. Other times, the SoS works much better if the best technical person from a team attends. Use common sense (which is uncommon).
8. Focus on the Teams. It is apparent that, as soon as you have a 'superstructure', people lose sight of the Teams and focus on the superstructure. Do not fall for that temptation. Of course, this is quite easy to say, and far harder to do. Again, everyone should focus mainly within the Teams, and on what each Team produces. As much as they possibly can.
Those few ideas should get you started. More later.
We are starting Scrum. We have the kind of projects that require scaling. But how do we start with Scrum and have some scaling?The first thing to say is: The basic framework of Scrum does not attempt to answer this question. It assumes you will use lean-agile-scrum principles and values, and devise your own, specific solution to this problem.
Still, the Scrum community has dealt with this problem many times. So, here is what Jeff Sutherland and Ken Schwaber and lots of others think are some good ideas to start with.
Let's assume you are talking about putting 3 teams together to work on one project. To release roughly every 4 months. Let's assume each team is about 7 people, including the PO and the SM.
Let's also assume that we continue to focus on Team success. Meaning: We realize that the core of activity is inside the Team. If each Team is not 'working', then no amount of scaling is going to help.
So, the Team's are real teams. Each person is 100% dedicated to one Team.
1. Chief Product Owner. Each team has a product owner, and, in addition, there is a Chief Product Owner -- who manages the Master Product Backlog for all 3 teams. So, the CPO is not dedicated to one Team, but to all 3 teams.
2. Product Owner group. The CPO and the 3 POs all work together. They meet daily, in a separate 'daily stand-up' (brief, 15-minutes) meeting. To be sure things are coordinated from the business side across all 3 teams.
3. Scrum of Scrums. SoS. This means a Daily Scrum across all 3 teams. Specifically, each Team does the usual Daily Scrum. Then, at least one person from each of the 3 teams comes to the Daily 'Scrum of Scrums'. The questions are: (a) what did your teams get done yesterday, (b) what will your team get done today, and (c) what is your team's biggest impediment. A Scrum of Scrums Master facilitates this meeting. And addresses the impediments.
4. Scrum of Scrums Master. There are few rules as to who this should be. It could be a manager who is not on any Team. It could be one of the ScrumMasters on one of the Teams. Etc. But this person becomes the 'impediment-remover-in-chief' for the impediments identified in the SoS.
5. Technical Issues. The main work of the SoS is to remove technical impediments. If a business side impediment is high, that probably would be given to the Product Owner group to address.
6. Continuous Integration. To have scaling across 3 teams, it quickly becomes very important to have much better CI (continuous integration). This is true with just Scrum for one team. But becomes extremely urgent with scaling with 3 teams. Because they are all playing in the same code base.
7. Attendees at the SoS. The initial idea is that the SMs from each team would form the SoS. This works fine some times. Other times, the SoS works much better if the best technical person from a team attends. Use common sense (which is uncommon).
8. Focus on the Teams. It is apparent that, as soon as you have a 'superstructure', people lose sight of the Teams and focus on the superstructure. Do not fall for that temptation. Of course, this is quite easy to say, and far harder to do. Again, everyone should focus mainly within the Teams, and on what each Team produces. As much as they possibly can.
Those few ideas should get you started. More later.
No comments:
Post a Comment