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…)

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…)

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…)

Pick a direction?

Pick a direction?

A Scum of Scrums (SoS) is a mechanism that has been adopted to coordinate a group of teams so that they act as a team of teams.  Historically the concept of a SoS was not part of the original Scrum framework and is considered an add-on to the framework.  In other words a Scrum of Scrums is an optional technique that can be added to more canonical Scrum framework if useful however because the technique is optional the amount of guidance is patchy.  For example, when an organization adopts a SoS who should participate is often hotly debated.  The participation debate popped up after we published Scrum of Scrums, The Basics. I had a number of conversations with readers to discuss the topic. Consolidating the discussions suggest the type of membership the person supports depends on what they want to get from using the SoS. All of the readers felt that the SoS should always be focused on coordination however there can be two flavors; one focused on activities and the second on technical questions.

Coordination of Activities:  Those that believe the SoS is primarily a tool for coordinating team activities support the idea that Scrum Masters should be chosen for SoS membership.  The rationale put forward focuses on the idea that the Scrum Master is uniquely positioned to gather and communicate information related to the coordination of teams. Readers in this group view feel that since Scrum Masters interact with all team members as a facilitator rather than a technical leader they are better coordinators. The alternate view held by many Agilistas believe that Scrum Masters acting in this role violate Scrum principles and represent a prima facie reinstitution of the role of the project manager. Further the Agilista view suggests that when technical issues need to be dealt with in SoS meetings populated with Scrum Masters they can’t make decisions rather often need to act as a conduit between technical team members. When SoS become a conduit, a version of the classic telephone game, decision making effectiveness is reduced..

Technical Coordination:  Fred Brooks in his essay Tar Pit (foreshadowing the next installment of Re-Read Saturday) suggests that software development increases in complexity as it progresses past development of an individual program. Integrating work with the work of other requires sharing technical information and making technical decisions that often can impact more than a single person or team. Scrum of scrums that are being used for technical coordination require participants with relevant technical acumen.  Participants with technical acumen generally come from the technical part of the team (developers, architects or testers).

Pushing aside the noise of whether the coordination of activities is less Agile than using the SoS for technical coordination, a more pragmatic approach is to recognize the needs of the team of teams is context driven.  The type of decision the team of team needs to make will change across a sprint or a SAFe Program Increment therefore who should attend a SoS needs to vary. The downside to varying membership is ensuring the right people are in attendance to address the SoS’s current need. One solution I have observed is to develop a cadence for topics.  For example tackle coordination every fourth SoS gathering with other more technical topics being focused on in-between.  Predictability makes it easy to plan who should attend.  Regardless of approach I suggest that any SoS should agree upon a mechanism to decide on the type of to hold. Flexibility to identify the type of SoS will ensure the team does not fall prey to meeting schedule paralysis or the equally evil telephone game.

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

The city is a town at scale.

The city is a town at a different scale.

The Scrum of Scrums is a common tool to scale Agile. In many cases the technique works admirably, however as Scrum-based Agile is applied to larger and larger projects, the Scrum of Scrums technique becomes stressed. The most significant issues include:

  1. As the number of Scrum teams involved on a project increases, the number of attendees increase. As the number of attendees that must talk in a meeting increases, the length of the meeting increases. The length of meeting is perfectly correlated to the number of emails sent by participant during the meeting. In other words, it is difficult to hold the attention of participants in larger, long meeting meetings. As projects grow, curtail the active participants to the team Scrum master /representative. In organizations where product owners wish to hold a Scrum of Scrum type meeting make sure those sessions are separated. I have also seen organizations experiment with hierarchies of Scrum of Scrums meetings.
  2. Project Coordination. Both Scrum of Scrum meetings and their cousins, daily stand-up meetings, are coordination and planning meetings. As the project size grows, coordination and planning meetings require greater context (status) to be effective, which can shift the focus towards informational or status meetings thereby reducing the effectiveness of the technique. Large projects need to have a mechanism for sharing context/status outside of planning and coordination meetings. One interesting solution I have observed (for a large program) was a daily program e-newsletter akin to the newsletter large conferences publish daily. I have also seen status wikis used to great effect. Status and news is easily consumed asynchronously therefore meeting time can be avoided.
  3. The Scrum of Scrums meeting infers a hierarchy in Scrum teams that does not exist. Scrum masters become the conduit of information between teams. Team communicate with their Scrum masters, Scrum masters communicate with other Scrum Masters then to the team they are part of and then the cycle reverses. A few years ago I read an article by Mike Cohn that suggested rotating participation. While rotation might impact the consistency, it would send a message that participation is a role rather than a status level.

Scaling Agile requires thought and planning. A Scrum of Scrums that includes product owners and other participants that worked for a handful of teams might need to be tailored when the project grows to include two or three handfuls of teams. Very few human institutions are linearly scalable forever. When using Scrum of Scrums for larger programs scale the technique rather than just moving to a larger conference room.