Scrum of Scrums are about the conversation!

The purpose and composition of a Scrum of Scrums (SoS) have been discussed in detail in earlier blog entries.As a means to scale, SoS has been leveraged as a structure for teams to coordinate and plan activities between each other.  The SoS is a platform for conversations such as negotiating access to a capacity from a team with specific skills or reminding everyone that you are refreshing the test environment in a few hours. The pattern of getting people together to coordinate with a structured approach in a time box is a powerful tool. That is why the base pattern has been tweaked and leveraged for many other purposes, some of which stray away from a few basics prerequisites:

  1. You have to have more than one team. It is difficult to coordinate if no one else is involved.   Just because you are doing Agile or Scrum does not mean that you need to leverage a Scrum of Scrums. Don’t think this has not happened.
  2. Participant teams need to interact with application or capability level.  Holding a Scrum of Scrums that have no functional or capability connection will devolve into a status meeting or worse.
  3. Participants need to have a valid reason to plan and coordinate together.  Even if participants share an application, project, technology or capability, they still need a reason to plan, coordinate and negotiate together or the SoS will be a status meeting.
  4. Participants must trust each other.  Without trust no real communication is possible.

A Scrum of Scrums is not a status meeting — the world does not need more status meetings. (more…)

10358869_10203282385195091_1761744082221812386_n

Different sort of pyramid syndrome

A Scrum of Scrums (SoS) is a mechanism to coordinate a group of teams so that they act as a team of teams. Powerful tools often have side effects that, if not countered, can do more harm than good. There are several “anti-patterns” that organizations adopt that negatively impact the value a SoS can deliver. In Scaling Agile: Scrum of Scrums: Anti-patterns Part 1 we explored The Soapbox, The Blame Game and Surrogate Project Manager, which three typical anti-patterns. Two other common anti-patterns are the Three Bears and Pyramid syndromes. (more…)

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

The idea of a Scrum of Scrums (SoS) is fairly simple. A bunch of people get together on periodic basis to coordinate the work their team is doing with other teams. The SoS helps everyone involved work together in order to deliver the maximum value. The SoS typically use the daily stand-up or scrum as a model. The simplicity of the logistics of the SoS and the overall utility often leads to tinkering with the format to address other organizational needs. Four very typical additions include: (more…)

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

The idea of a Scrum of Scrums (SoS) is fairly simple. A bunch of people get together on periodic basis to coordinate the work their team is doing with other teams. The SoS helps everyone involved work together in order to deliver the maximum value. The SoS typically use the daily stand-up or scrum as a model. The simplicity of the logistics of the SoS and the overall utility often leads to tinkering with the format to address other organizational needs. Four very typical additions include:

1.     SoS Hierarchy. As projects get larger, more than one scrum team is often needed to deliver the functionality and value needed by the business in a timely fashion. Any time more than one team has to work together, you need to coordinate to ensure that the teams don’t get in each other’s way. A simple Scrum of Scrums will typically suffice for coordination of a few teams; however, as soon as the number of teams grows to between 7 -10 a single SoS will begin to lose its effectiveness. When a SoS gets too large it generally needs to be split into two, and once you have two SoSs . . . you will need a third. If a project requires ten teams to deliver, then three SoSs will be needed. Two five-person SOSs would meet and then send a representative to the third to coordinate and pass information. Hypothetically SOSs could scale infinitely. However in scenarios requiring more than two layers of SoS, effectiveness usually suffers due to degraded communications and meeting fatigue.

2.     Backlogs. Scrum of Scrums, even those with variable membership, often build up lists of to-do items that need to be tackled by SoS members outside of the meeting. These to-do items often do not belong on the backlog of the everyday team. ANY item that a SoS needs to tackle belongs on a backlog (or a to-do list). Most SoS teams I coach use Scrumban to prioritize and the work items on their backlog. Items on the backlog are often varied. For example, some the items I have seen on SoS backlogs included: tasks for consolidated demos, release planning tasks, activities for coordinating external reviews, training and even team events. Using a backlog allows the SoS to capture and prioritize work that both affects and requires coordination across multiple teams.

3.     Retrospectives. I have never met a team that could not benefit from a retrospective at some point. Scrum of Scrums teams are no different. Standard retrospective techniques can typically be used without modification. One exception to standard approaches are for SoS retrospectives for teams with variable membership. For example, in cases where common patterns occur, such as scrum masters one day, technical leads meeting on another day and perhaps test leads a third day. In this case I suggest holding three separate retrospectives. In cases where membership purely depends on daily context, I usually invite everyone that attended the SoS within the timeframe being addressed. One side note, I tend to do SoS retrospective(s) over a lunch at the end of sprint to minimize the potential for time contention with the ability of SoS participants to work with their regular team.

4.     Planning. Where there is a backlog and a cadence of events, there needs to be planning. A SoS team should plan its activities. Planning should include the number and cadence of meetings, membership and any outside activities that the SoS might need to address. Planning should be done at the beginning of a sprint and then tuned on a daily basis. I typically add 30 minutes to the first SoS meeting to address logistics and planning (a form of sprint planning) and then have the SoS team(s) work the backlog as part of their meetings. Asking the SoS to plan its own schedule sends a message about the need for teams to self-organize and self-manage.

The four typical additions of hierarchy, planning, backlogs and retrospectives are consistent with the principles of Agile. These additions add a layer of transparency and coordination. The simplicity and effectiveness of the SoS (and the daily stand-up for that matter) often generate suggestion add extras to the meeting. Use the concept of the time box, for example limit all meetings of this type to 15 minutes, and the principles of Agile to ensure that additions don’t reduce the effectiveness of the Scrum of Scrums. Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

10358869_10203282385195091_1761744082221812386_n

Different sort of pyramid syndrome

A Scrum of Scrums (SoS) is a mechanism to coordinate a group of teams so that they act as a team of teams. Powerful tools often have side effects that, if not countered, can do more harm than good. There are several “anti-patterns” that organizations adopt that negatively impact the value a SoS can deliver. In Scaling Agile: Scrum of Scrums: Anti-patterns Part 1 we explored The Soapbox, The Blame Game and Surrogate Project Manager, which three typical anti-patterns. Two other common anti-patterns are the Three Bears and Pyramid syndromes. (more…)

Heads up!

Heads up!

A Scum of Scrums (SoS) is a mechanism to coordinate a group of teams so that they act as a team of teams.  SoS is a powerful tool. As with any powerful tool, if you use it wrong, problems will ensue. Six problematic implementations, called anti-patterns, are fairly common. We’ll discuss three in part 1 and finish the rest in part 2. (more…)

Scaling - going from one project to two (or more!)

Scaling – going from one project to two (or more!)

The Scrum of Scrums (SoS) is a technique for scaling Scrum and other Agile techniques to larger efforts. On paper, the SoS is a simple extrapolation of the daily Scrum or stand-up meeting that has become a hallmark of the practice of Agile. A typical stand-up meeting occurs on a daily basis so that all of the team members of can coordinate and plan daily activities. Classically the team uses the three question technique to organize the meeting. In a similar manner, a typical Scrum of Scrums acts as a focal point to help synchronize a team of teams or even teams of teams. There are four basics of a SoS that need to be understood before any nuances can be addressed.

  1. Who Attends: There are two basic schools of thought in picking SoS attendees. The first (and most common) school suggests that the Scrum Master attend the SoS. The Scaled Agile Framework Enterprise (SAFe) is an example of a methodology that leverages the Scrum Master during both the planning event and during the program increment. Alternately, the second group takes a more egalitarian approach (possibly more pragmatic) allowing the each team to select an attendee that can most easily convey or understand the current issues the team and the larger group are having at the time. For example, if design decisions are at the front, perhaps team members with the most UX acumen would make sense. In this scenario attendees would vary over time.
  2. Who Facilitates: Small SoS groups, for example a handful of teams that are co-located, may not require facilitation. The SoS can self-organize and execute the meeting with little overhead. However as the number of participants increases (I bound SoS meetings using the same 5 -9 members rule used in Scrum teams) or as the distribution of the members becomes more varied facilitation becomes more important. Facilitators help the team use the SoS practice, ensure logistics are set up and champion the schedule. In larger efforts, a program manager often delivers facilitation, or if practicing SAFe the Release Train Engineer performs the facilitation role.
  3. Frequency: Scrum of Scrums often follows the same pattern as the daily Scrum/stand-up meeting. A second frequency pattern is risk-based; the frequency of the SoS meetings varies depending on need. Early in a project the SoS meets daily as teams are forming, norming and as early decisions are being made. The SoS meeting become twice weekly in the middle of the project and then returns to daily as a release approaches.
  4. Format: Daily stand-up meetings commonly leverage the classic three question approach (What did I do? What am I going to do? and What are my blockers?). The Scrum of Scrums generally follows a VERY similar format with each participant answering the following four questions:
    1. What did my team do since the last meeting?
    2. What will my team do before we meet again?
    3. Is my team experiencing blockers?
    4. Is my team going to put something in another team’s path?

The meeting follows the same round robin approach with each participant interacting with each other. The facilitator (if used) should never be the focal point of the meeting, nor should the SoS devolve into a purely a status meeting.

The daily stand-up and the SoS are very similar meetings. Both meetings are held to share information, coordinate activities and to identify problems. The scope of SoS meeting is broader than a single team with the meeting providing coordination and planning activities within and across teams.

Next: Using the Scrum of Scrums to Scale Planning and Scrum of Scrum Anti-patterns