Starting with Scaling

Question:

“We are starting Scrum. We have the kind of projects that require scaling.
But how do we start with Scrum and have some scaling?”

Answer: 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.

Scrum is not attempting to be a full methodology, but only a bare framework.

Still, the Scrum community has dealt with this problem many, many times.  Here are some good ideas to start.  (Later, we will get to more complex aspects.)

Let’s assume:

• You are talking about putting 3 teams together to work on one project.
• To release roughly every 2-4 months.
• Each team is about 7 people, including the PO and the SM.
• Continue to focus on Team success.  Meaning: Realize that the core of real energy is inside the Team.  If each Team is not ‘working’, then no amount of scaling is going to help.  So, the Teams are real teams. Each person is 100% dedicated to one Team.

OK, now you have some of the basics. Let’s talk about scaling…

1. Chief Product Owner.  Each team has a product owner, and, in addition, there is a Chief Product Owner ‘over’ all 3 teams — who manages the Master Product Backlog for all 3 teams.  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 quick daily meeting, Like a ‘daily stand-up’ to be sure things are coordinated from the business side across all 3 teams. Similar to a ‘scrum of scrums’ (see below).  Make the meeting short and effective.
3. Scrum of Scrums.  SoS.  This is very much like a Daily Scrum, but at the team level, and across all 3 teams. Specifically, earlier each Team does the usual Daily Scrum.  Then, after that, at least one person from each of the 3 teams comes to the Daily ‘Scrum of Scrums’.
   The questions are:
   (a) what did your team 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 helps address the impediments.
4. Scrum of Scrums Master.  There are a few ideas about who this might 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 might 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 also true with just Scrum for one team. It 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 sometimes.  Other times, the SoS works much better if the best technical person from each team attends.  Use common sense (which is uncommon).
8. Focus on the Teams. It is apparent that, as soon as you have a ‘superstructure’ of scaling, people lose sight of the Teams and focus on the superstructure. Do not fall for that temptation.  (Ok, fall for it less.) Of course, this is quite easy to say, and far harder to do.  Again, everyone should focus mainly making each Team more effective, and on what each Team produces, as much as they possibly can.
9. Scale down.  Learn to ‘scale’ with 3 teams.  Once you have all these patterns working well with 3 teams (and maybe other patterns not named here), only then consider scaling say 4 or 5 teams.  KISS.  Keep it stupid simple.  Crawl before you even think of running, we often say.

These few ideas should get you started.  More later.

 

« « The ScrumButt Test (1): Iterations must be timeboxed || Impediments (or symptoms of) – Montreal Class July 2013 » »