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.

Cargo ships on Lake Erie

The bigger the ships, the more barnacles.

As we noted in Agile Charter Barnacles, the basic Agile project charter is brief and to the point. However, there is a natural tendency to add components back from classic charters.  The charter is a tool for the team, therefore the team needs to find the components that add value to how they work.  When these components add value, adding these sections makes sense.  A number of readers of the Software Process and Measurement blog have asked about whether adding specific charter sections make sense in an Agile project or whether there are other techniques to address their needs. Here are my answers: (more…)

Men fishing in a boat with an outboard motor

Barnacles slow down the boat.

The basic Agile project charter is brief and to the point. This brevity seems to beg practitioners to add components from classic charters. Here are some examples of common barnacles: (more…)

Barnacles attach to ships and add drag

Barnacles attach to ships and add drag

In earlier entries of the Daily Process Thoughts, I believe we have established that basic Scrum process can be defined using three roles, five events and three artifacts. This is the Scrum canon, much like the canon of stories that make up the Sherlock Holmes series. Many organizations and consultants have added practices to Scrum in order to meet specific needs (if those needs are real or perceived is an open question).  At the Scrum Gathering in Las Vegas in 2013, Dr. Alistair Cockburn called these additions barnacles; Ken Schwaber has written extensively about “Scrum buts. . .” and “Scrum ands. . .”. Barnacles grow on the hull of ships and create drag, slowing the ship or requiring greater energy to drive the same distance. However for all of the downsides of a barnacles they serve a purpose, deliver a benefit, or they would not exist in nature.  The additions to Scrum must compete and deliver value or they will be swept aside.  Several of the more common barnacles are related to defining and estimating work. They include:

  • User Stories, phrased in the now classic “persona, goal, benefit” format, are an addition to the canon of Scrum.  User stories provide a disciplined framework for describing units of work, which improves communication.
  • Story Cards, which generally include the user story, acceptance criteria, size and other ancillary pieces of information, provide a means to the organize units of work a team will be working on.  Organization of information provides a means of visualizing gaps and keeping track of work items so they can be communicated (and in my case, so they don’t get lost).
  • Story Points, are a representation of the size of a user story or any unit of work based on the collective understanding of the team that is being tasked to deliver the work.  The use of story points provides a team with a consistent scale that helps team members communicate about their perception of size.
  • Planning poker, a variant of the Delphi estimation process, acts as mechanism to structure the discussion of size and estimation within Agile teams to increase communication, ensure all relevant voices are heard and to control paralysis by filibuster.

Add to the potential additions technical practices like Test Driven Development, Behavior Driven Development, Continuous Builds and hybrids like Scrumban and the number of potential barnacles can grow quite large.  That is the nature of a framework.  Techniques, practices and processes are bolted on to the framework first to see if they improve performance.  As practitioners and methodologists we must insure that only those that provide tangible, demonstrable value are allowed to stay bolted.  Remember that each organization and team may require more or less barnacles to be effective.  Like the Sherlock Holmes stories, others have extended the canon with their own stories, practices and process.  Some are valuable and find traction, while others are experiments that have run their course.