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

This builds on Scaling Scrum (3-4 teams) (Part 1) Part 1 looked at the situation where there were multiple teams working on a single product. This will look at instances where there are multiple teams working on different projects/products in the same organisation. i.e. each team has a different backlog. Remember the rule though 1 product = 1 backlog!
What we are going to do here is to make sure that separate products/projects are in sync with each other and dependencies are made visible and met with minimal delay.

Some examples may be:

• A Web front end that feeds an e-mailing system that needs a new template created
• Sales Order information that will eventually end up in a data warehouse
• The customer Journey through a web site that is fed into a marketing system for further analysis.
  

OK, I can hear the purists shouting already “The team should consist of members that can address the feature from end-to-end”. I could not agree more. However, when we need to work within the constraints imposed by the business while still delivering viable product. There are going to be times when this sis just not feasible or possible and we need to be pragmatic, take a considered view and do the best we can.

The key to making this work is to make sure that each piece of work can be built, tested and accepted in the same sprint without relying on work done/not done by other teams. This means that you need to be very careful how you build things and your Product Owner must know how you are working and how to validate and accept the completed work.

Before we even get to this point though, we need to make sure that we know what each team needs to do,when they are going to do it and how they are getting on with doing it.

Part 1 talked about a Backlog refinement session to work ahead on the backlog. This is now even more important, but now needs to react to input from a “Story Mapping” session. More n Story mapping later, but initially it could be as single as a list of those stories expected to be played on the next 3 of 4 sprints. The work for each team is compared with that of the others and any dependent or supporting work identified and prioritised there and then. To do this you will need a least your PO’s along with suitable Technical or SME’s also attending. Granted you may not be able to create fully fledged stories, but you need to create stories that capture the essence and can be further fleshed out as needed. It is key that the fact another team is relying on this work is made visible n the story. This is not to make sure that extra attention is paid to it, but rather to make sure that during planning sessions, it is not de-prioritised and ‘planned out’ of a sprint. This will make sure that each teams work is delivered when expected and dependencies met.

As should be evident a Scrum of Scrums is now even more important, as is planning. It also means that the Product owners and Scrum Masters need to be on their toes.

As mentioned earlier, each teams piece of work must be able to be delivered and accepted individually. You can’t get into a situation where you are told, ”I can’t accept this teams work as that teams work is not done and I can test it end-to-end”. This should he been sorted before you planned the sprint. The way you get around this will depent on the technology you are using, but could include the use of stubs, or mocking frameworks, services that consume but not process data, switches that toggle functionality until the output can be consumed etc. Agreed this means work but it is well worth it in the long run.