You are here

Scaling Scrum (3-4 teams) (Part 1)

Body: 

Scaling Scrum is easy, have a look at the Scrum guide at http://www.scrumguides.org . You have a number of teams that each operate as normal and a member from each of the team attends an additional daily scrum. Yes, it all makes sense, but it is a lot easier to say than do, even on a small scale. There are a few practical things that newer teams and organisations need to think about and do other things will descend into a state of anarchy.

By and large there are two sets of circumstances where you need to scale.

  1. Where the product/project is too large for a single Scrum team
  2. Where there are multiple teams working on different products/projects in the same organisation (with the potential to impact each other)

Where you have a mix of these, combine the techniques for each.

This blog will look at simple techniques to use to scale Scrum when the product/Project is too big for a single Scrum Team.
The cardinal rule here is One Product, One product Backlog. As tempting as it may be, and no matter how much pressure you get put under, never never break this rule. You will regret it! You will probably get the most pressure from the teams, with the most common reason being that it will make it easier to manager their work. All good and well until you state the obvious. Each team is responsible for their Sprint/Iteration backlog (What happens inside the sprint), but the Product Owner is responsible for the rest of the backlog, All of it.
They need to have that single view of the product, that depending in how it is structured shows how work is related, but more importantly, how it is ordered. What is most valuable, where do we need to focus next. Doing this is difficult enough with a single backlog and almost impossible when it has been split. Planning becomes an absolute nightmare.
It also introduces the problem of which backlog a new bug lands in: The team that last touched the area, the team that did the original work a random backlog, the tam that the person doing the work is now on, or horror of horrors another backlog. Agreed, your automated testing and continuous integration should reduce the incidence of these, but resolving this even for a single bug costs time and effort (=money) and breeds bad feeling and conflict. Maintain a single backlog if you value your sanity.
Producing those reports that you as a servant to the business need to create is also complicated an now takes longer. you now have to check and combine two sets of numbers rather than one. All this is wasted effort, something to avoid at all costs.
Not having that single view of the product and its priorities is by far the biggest problem and has a far reaching impact.

OK the I have one Backlog and two teams, how do I handle the other Scrum events then?

Sprint planning is simple. There is a single planning session that is attended by both teams, the PO and any architects. This way all teams have a good view of what is happening and any conflicts can be quickly and easily resolved. What this also does is make sure that the teams are using the same currency to estimate and that the exchange rate is the same (My points are the same as your points even though we are on different teams). It may also be the case that a piece of work may be more suited to one team that another. (Either team should be able to do it, but you may move things to spread knowledge etc.) It also means that pieces of can easily be split or merged with everybody knowing what is going on. You will however create a separate Sprint backlog for each team.

Daily Scrum or Standup. Don't have a single standup! Make sure each team has a daily standup at a time that suit everyone. They could be at the same time, they could be one after the other, whatever. Do your best though to keep them as close together as possible and definitely in the same half of the day.

Sprint review Here I would again have a single session. There are bound to be pieces of work that are best shown together or consecutively to have the best/biggest impact. It will also make scheduling a lot easier and you will have a better chance of getting people from the wider business attending.

Sprint Retrospective I feel that a retrospective for each team works better. They can then focus on issues hat are particular to them and have a better chance of being progressed. It also helps to keep the session focused with better participation. Make sure that you share learning and best practice across teams.

Scrum of Scrums Now that we have multiple teams, we need a SoS this is in reality nothing other than a daily standup at a slightly higher level. it is there to Plan, Identify impediments, indicate current progress and likely next steps. Make sure that you go over all sprint backlogs and have at least 1 and possibly 2 members from each team attend.

Backlog grooming/refinement In a previous blog I have promoted the initiation of specific Backlog grooming/refinement sessions. This becomes even more important now as it is key to making sure that you look ahead and coordinate the upcoming work to all teams and make sure that the Product Backlog is in a good state with enough work at he right size and 'ready to play'. A good technique here is to use 'Story or Feature mapping' (more on this in a later blog)This is especially important when you have multiple teams working on separate but dependent features or products.

If you need to 'Go Large' you can look at things like SAFe and other frameworks, but I suggest that you start with the basics and grow from there.

Keep an eye out for a later blog focussing on multiple teams and different but dependent products.