[teampractices] Scrum of scrums

[Bryan Davis]

Hello list!

Two separate people forwarded this message to me and asked me to a)
join the list and b) provide input, so here I am.

 I don't have a completely formed argument to provide on this as I am
both new to the organization and not currently embedded in a true
scrum team, but I'll try to provide some anecdotes from prior
practice.

> Examples of problems that I think are worth solving:
> - Ensuring platform and ops are in the loop on the latest shiny
> features you're building
> - Surfacing perceived blockers ("we're still waiting on the Varnish
> migration til we can release X, so we've moved on to Y")
> - Ensuring feature developers are in the loop on new services/APIs
> that are being built that can be used by feature devs
> - Surfacing questions about prioritization ("Ops: we've been asked to
> work on OSM" - "Mobile: we should probably talk to the mobile PM to
> figure out how urgent that is")

These are exactly the sort of issues that led to implementing scrum of
scrums communication at $DAYJOB-1. An additional problem that we faced
(and I believe is faced here) was the need to interface scrum teams
and non-scrum "consultants" within the organization. In our case,
Operations, Accounting, Legal and Customer Services were all
"consultant" roles the scrum teams. This means that there were not
typically embedded representatives of these groups within the teams
themselves.

Experimentation is generally needed to determine the right mix of
frequency, duration and attendance that produces a good level of
communication without a burdensome amount of overhead for the
participants. When I have employed this practice previously it was
generally a weekly meeting with a duration of 5 minutes per team
represented. With a large number of teams (>6) it can be very helpful
to scale up by holding a scrum of scrums of scrums rather than
attempting to directly interface all teams. It is also useful to form
and disband smaller scrum of scrum teams meeting at higher frequency
at particular project inflection points such as the last few sprints
of a major feature release or the run up to a cutting a new shippable
product version.

This should be a meeting for pigs[0] meaning that the purpose is not
to provide management with yet another view of the roadmap progress of
the individual teams. The intent is to surface inter-team issues as
early as possible before each team's individual increment is
endangered by roadblocks.

> In our context, this may be the kind of meeting where note-taking
> would be useful. For example, a daily email to engineering@ including
> the notes could be helpful. But that's just an idea.

A scrum of scrums should be treated as any other scrum team. This
means that their workings should be visible and inspectable at all
times. There should definitely be tangible artifacts that are
available to all members of the organization. At $DAYJOB-1 this took
the form of a hallway whiteboard that documented the next week's
milestones and current blockers. The scrum of scrums team was
responsible for keeping this artifact up to date on at least a weekly
basis. In this environment I would imagine that a wiki page would
replace the whiteboard to be more accessible to remote staff.


[0]: https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig

Bryan
-- 
Bryan Davis              Wikimedia Foundation    <bd808 at wikimedia.org>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer                Boise, ID
irc: bd808                                        v:415.839.6885 x6855