Article of the week 3 – 2023

Scrum of Scrums in the agile development environment

The advantages of agile development in digital transformation projects and programs within and outside of customer services have been confirmed and established in for a long time, in recent years. It is also becoming increasingly successful in dovetailing with existing waterfall models purported by the organization, which must operate with fixed releases, timelines or iterations.

After all, „agile development“ does not mean that you do not have to produce results by fixed deadlines. It means exactly the opposite, namely that you move much more precisely towards the goal/result, while maintaining a high degree of flexibility along the way in order to achieve precisely this goal in return.

Too many parallel agile projects?

As a rule, however, agile projects do not run individually and in isolation. Rather, several projects usually run in parallel in this structure once agreed upon. In addition, depending on the needs, the scaling of the teams as well as overlaps with other agile projects change during the project – temporarily or even permanently.

There is often a predetermined breaking point here, which we want to take a closer look at in this article of the week. How do you ensure that many agile projects operating in parallel do not act in isolation, that the corresponding development statuses remain transparent, and that dependencies or effects on the respective projects are assessed, prioritized and controlled?

Of course, you can try to embed the respective individual projects in an overall backlog active one-char overview or a Kanban board. However, with the increasing number of projects, tasks and their descriptions, requirements, acceptance criteria, DoD…. etc., this becomes very confusing at some point and one loses the overview. Especially the overview of dependencies or overlaps, since the teams still mostly operate within their own lanes.

More overview through Scrum of Scrums

One solution is to establish a Scrum of Scrums (SoS) structure. The principle of Scrum of Scrums is very much based on the classic Scrum approach and offers the possibility to keep Scrum organizations or projects agilely scalable.

It is important to consider the following elements:

• Which representatives of the respective individual agile projects need to be on this SoS board?
  This could be a product owner, tribe lead, squad lead, application owner or similar.

• Which framework should be used for this SoS, which prioritization and/or success criteria or KPIs are essential?
  Overarching goals are recommended here, which are strongly oriented towards the essential company KPIs. Provide a tracking system that visualizes the overall success (!) based on the defined KPIs.  

• Define an SoS Scrum Master who is accepted by all stakeholders.
  This person has sound knowledge of the company’s overarching programs/initiatives and ideally good knowledge of the individual projects as well as overlaps and dependencies.

• What frequency of regular communication makes sense for the team or parts of the team? Here it is advisable to conduct a daily standup after the other standups of the individual projects, analogous to individual Scrums, since all current information, plans and changes are then available. In addition, a SoS sprint should take place in parallel with the sprints of the other measures. As a result, a refinement within the SoS can also lead to changes in other individual sprints, if essential enablers or dependencies make this seem sensible.

• How is the information and the respective individual project status processed and documented?
  The recommendation is that the respective tribe or squad leads only aggregate the tasks that are either highly relevant, time-critical and/or have overlaps/dependencies with other projects and dump them on the SoS board.

• How do I determine whether the SoS is successfully set up and functioning?
  There is no standard solution or procedure here. Indicators can be: How good is the participation and involvement of stakeholders within the regular meetings? How many appointments can be completed in the given time window? How many unknown dependencies/risks occur despite coordination? How good is the documentation quality?

• Extra tip: An agile coach can be a good support solution, especially at the start of a SoS introduction, until the respective working methods and procedures have become established in the team as a whole, and can moderate conflicts between the respective stakeholders, especially at the start.

Summary

A Scrum of Scrums structure is not an all-purpose solution for all situations, and depending on the team or project size, or in the case of a deliberately isolated project without overlaps into other areas, a pure Kanban approach without a more personnel-intensive Scrum organization, for example, can be a pragmatic and more cost-effective approach.  

However, the more parallel agile projects you start and the more dependencies and overlaps and conflicts of interest arise, the more helpful it is to establish an overall control in the sense of agile multi-project management from an overall company perspective. And SoS can indeed be a good solution for this.

Carlos Carvalho –  Senior Consultant

 junokai