… a Scrum Team is working on a single product with multiple Development/Delivery Teams. The Development/Delivery Teams need to coordinate dependencies and shared work. Dependencies that cannot be resolved within individual teams are a shared challenge of all teams.

✥      ✥      ✥

When multiple teams work independently of each other they tend to focus myopically on their own concerns and lose sight of any common goals.

Organizations might revert to a command-and-control approach in the false belief that agility only works at the scale of one-team, but complexity has grown, not diminished, in this circumstance. Hierarchical control  increases delays and reduces the responsiveness of the teams and the wider organization to business and technology changes.

The product could be broken into smaller pieces, each of which could be worked on separately by different teams, but the Taylorist idea [1] that optimization of the whole follows from optimizing each local part does not work in environments dominated by complexity ([2], [3]). Unexpected dependencies arise between the work efforts, slowing delivery, and reducing the ability of the organization to respond to change.

The separate teams could coalesce into a single, undifferentiated team but the communication and co-ordination overhead would grow exponentially causing informal sub-groups to appear, probably along demarcation lines that would mean they were less than cross-functional.

The multiple teams could report to a common manager or management function which then distributed the work amongst the Development/Delivery Teams, and would be charged with the responsibility of resolving dependencies, blockers and other inter-team issues as they arose. However, this approach surrenders the autonomy of the teams, lowers their investment in the product (their sense of having “skin in the game”), reduces responsiveness and flexibility, and incurs a further price in lowering the amount of learning that can be garnered during development. Richard Hackman, in his book Leading Teams [11], claims that successful teams are aware of and handle their surroundings themselves, which in this case means they would handle their coordination with other teams. Rosabeth Moss Kanter of the Harvard Business School, in her study of empowerment in the workplace has written that as the world becomes more disruptive, “the number of ‘exceptions’ and change requirements go up, and companies must rely on more and more of their people to make decisions on matters for which a routine response may not exist . . .” [4]. At the same time, experience shows that genuine autonomy is only exercised when teams and individuals accept responsibility — and accountability — for their decision-making. While the space for autonomous decision-making may be created 'from above,' only an intention from those 'below' to occupy that space can make self-governance a reality. [5]

Self-governing teams are not only more responsive and adaptive to change, they are the only sustainable source of job satisfaction. [6] On the other hand autonomy without alignment can lead to teams moving off in different directions, to the detriment of both the product and the organization [7].

Therefore: 

Give the right and the responsibility to collaborate on delivering common goals identified by the Product Owner to the Development/Delivery Teams themselves. Permit the teams to figure out the best way to coordinate their efforts.

✥      ✥      ✥

Successful alignment requires that everyone involved in the development, in every team, must have visibility of the product as a whole, its vision and its goals. This will typically involve expansion of the Product Owner Team to a level judged by the Scrum Team to be appropriate. Development/Delivery Teams will use some of their capacity to support the Product Owner.

Scaling, when it does occur, is always situational, so the exact forms of collaboration will be determined by the Development/Delivery Teams, but typical tactics include:

• Sprinting together – at the same cadence, at the same time, using Organizational Sprint Pulse
• Maintaining a common Definition of Done
• Common Sprint Planning, Sprint Reviews and other mandatory Scrum events
• Holding Backlog Refinement events in common
• Creating semi-formal optimizing networks of Birds of a Feather, utilizing common skillsets such as architecture, across the teams to proactively handle issues that are known in advance
• Holding a regular Scrum of Scrums meeting [8], perhaps daily, after the teams’ Daily Scrum events to resolve emergent dependencies and issues, and to get things to Done.

Whatever the formal arrangements for coordinating dependencies and discussing impediments, their resolution should not be postponed until the Scrum of Scrums event. The teams work on the impediments as soon as they emerge. When teams need to coordinate, the teams can just talk to each other without waiting for the next meeting on the schedule. Development/Delivery Teams organize themselves to get their work done and minimize dependency risk using Dependencies First. The ScrumMasters help to remove impediments to the Development/Delivery Team’s progress and can invoke the Emergency Procedure as a last resort. It is the level of spontaneous interaction, and unscripted collaboration between teams and teams’ members that is the true measure of the effectiveness of the Scrum of Scrums.

For a team member or team to exercise the initiative to bring an issue to the Scrum of Scrums should be borne not out of fear or even duty, but out of Product Pride.

The Scrum of Scrums is a well established pattern, first implemented at IDX Systems (now GE Healthcare) in 1996. Jeff Sutherland was Senior Vice-President of Engineering, with Ken Schwaber on board to help roll out Scrum as a consultant. There were eight business units, each with multiple product lines. Each product had its own Scrum of Scrums, some products had multiple Scrum of Scrums with a higher level Scrum of Scrums. Every product had to deliver to the market with a release cycle of three months or less and all products had to be fully integrated, upgraded, and deployed every six months to support regional healthcare providers like the Stanford Health System. It is clear from this example that there may be multiple, even parallel Scrum of Scrums and even that that a daily Scrum of Scrums (considered as an event) can split into sub-meetings with separate foci. The first publication mentioning Scrum of Scrums was in 2001 [9] and it is also referred to in the Scrum Papers [7] in 2011.

[1] Taylor F.W., Principles of Scientific Management. New York. Harper.1923

[2] Thomas F. Burgen, “Making the Leap to Agility: Defining and Achieving Agile Manufacturing through Business Process Redesign and Business Network Redesign.” International Journal of Operations and Production Management. Vol 14 Issue 11, pp. 23-24.

[3] Claude R. Duguay, Sylvain Landry and Frederico Pasin, “From Mass Production to Flexible/Agile Production.” International Journal of Operations and Production Management. Vol 17, Issue 12, pp. 1183-1195.

[4] Rosabeth Moss Kanter. Change Masters: Innovation and Entrepreneurship in the American Corporation. New York: Touchstone 1984, p. 18.

[5] See, for example, Daniel Katz and Robert Luis. Kahn. The Social Psychology of Organizations. New Jersey. John Wiley and Sons. 1966.

[6] Christopher Alexander, Sarah Ishikawa and Murray Silverstein with Max Jacobson, Ingrid Fiksdahl-King and Shlomo Angel. A Pattern Language: Towns, Buildings, Construction. New York: Oxford University Press 1977, p. 398.

[7] Charles Heckscher. “The Limits of Participatory Management.” In Across The Board. Volume 54. November-December 1995. pp14-21

[8] The Scrum of Scrums as a daily meeting of ‘ambassadors’ from multiple teams is described on the Agile Alliance website https://www.agilealliance.org/.

[9] Jeff Sutherland, “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies.” In Cutter IT Journal: The Great Methodology Debate, Part 1. Volume 14, number 12, December 2001, pp. 5-11.

[10] Jeff Sutherland, The Scrum Papers, http://scruminc.com/scrumpapers.pdf, accessed 11 January 2017, no permalink, draft, 29 January, 2011.

[11] Richard Hackman, Leading Teams, Harvard Business Review Press; 1 edition July 15, 2002.

Picture from: Greg Neate, www.flickr.com/photos/neate_photos/3522905573/in/album-72157617918428883, (under CC BY 2.0 license).