[teampractices] Scrum of scrums

Mon Sep 23 23:23:44 UTC 2013

I think we need to be clear about the issues we can and cannot address with
a meeting like the SoS. There are a lot of challenges we face staying
unified in engineering, and I don't think a SoS can (or should) address all
of them. From my perspective, a high-frequency meeting with reps from
multiple teams (like SoS) can help us achieve:

* Better inter-team communication, primarily from a tactical (as opposed to
strategic) perspective
* Better coping with integration challenges
* Better dealing with dependency management across product areas
* Improvements around general change management across product areas
* Having a shared view into the day-to-day activities of individual teams
* A forum in which to make commitments to one another (eg we will make sure
to get patchset X reviewed by Thursday in an effort to unblock your team)
* Identifying where further communication is needed between two or more
teams

Ultimately, I think this can be boiled down to: *tactical dependency
management between teams *with a byproduct of* increased communication and
on-the-ground transparency* between teams.

For those of you practicing scrum or something scrum-ish, it's just the
daily scrum but slightly bigger-picture. As such, I think this meeting
would NOT be good for things like:

* Addressing prioritization
* Strategic planning
* Big-picture or multiple weeks-forward planning
* Roadmap adjustments
* Planning bigger-deal collaboration (eg Mobile Web needs a VE engineer for
three weeks to accomplish XYZ)

Prioritization, big deal collaboration, long-term planning, etc should
happen in a different venue. I'm not sure how much cross-team collaboration
goes into this kind of stuff at the moment, but I think it's beyond the
scope of the SoS.

To sum up, the scope of the SoS is fairly limited - primarily to discussing
current roadblocks or immediately upcoming things (like, things coming up
before the next time the SoS meets). If something comes up that's out of
scope, the meeting facilitator should encourage that conversation to
continue outside of the SoS. Like the daily scrum, this should not be
strictly a status update - it should be a conversation, kept relevant to
participants, in which commitments are made and blockers/scary issues are
identified. If we can stay strict about the timebox and the scope of
conversation, I have faith that a SoS will not turn into the feature team
meetings of yore :)

*I propose the following:*
* twice-weekly SoS (maybe Tu/Th)
* one rep from each team that wants to participate (mobile web, analytics,
and ops have already committed)
* 30 minute timebox
* The following questions are addressed:
** What has your team done since we last met?
** What will your team do before we meet again?
** Is anything slowing your team down or getting in their way?
** Are you about to put something in another team’s way?
* Any conversation out of scope is handled appropriately by facilitator
(scrum of scrums master?)
* Notes should be taken and archived (via engineering@?)
* It is the responsibility of the team rep to disseminate appropriate
information to their team/ensure commitments made during SoS are fulfilled
* Keep the meeting open to chickens[0], but only allow them to actively
participate in the conversation as needed
* We start as early as next week to try it out (maybe 1 October if folks
agree to Tu/Th)

And of course, I suggest this as a starting point; it ought to adjust as
necessary. I think that this can be workable and valuable for all teams in
engineering, even those not working scrumishly (eg ops). I feel strongly
that a SoS will need active facilitation to keep to the timebox/keep the
conversation within scope. We could either have a rotating facilitator
(maybe each team takes turns facilitating) or we can consense on/have
decided for us a dedicated facilitator - I don't much care one way or the
other (I see merits to both approaches).

I think if we have a critical mass[1] on board, we should go for it. We've
already got mobile web, ops, and analytics committed to participating in
something SoS-flavored - in order to achieve critical mass, I think we need
at least one more team focussed on user-facing features (eg i18n/l10n,
visual editor, flow, etc) to participate.

So, thoughts on the proposal? Any other teams want to be involved in SoS?

[0] https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig
[1] https://en.wikipedia.org/wiki/Critical_mass_(sociodynamics)

On Sun, Sep 22, 2013 at 1:35 PM, Toby Negrin <tnegrin at wikimedia.org> wrote:

> Could we try having a SoS with a relatively small number of attendees
> initially, perhaps even from only a few teams? That might help streamline
> the process before we roll out it to everybody. (I'm a big fan of
> prototyping :)
>
> To address Amir's totally valid comments directly, I'd hope that if we
> make this meeting about communication and co-ordination it will be still be
> useful for non-scrum teams.
>
> Because a lot of people will end up attending this meeting, we should a)
> keep it very quick and make sure that issues are discussed in depth in
> another forum b) keep only the next few sprints/releases in scope for
> pretty much the same reason.
>
> -Toby
>
>
> On Sat, Sep 21, 2013 at 11:38 AM, Amir E. Aharoni <
> amir.aharoni at mail.huji.ac.il> wrote:
>
>> The Language Engineering team has been trying, quite successfully, to
>> practice Scrum (or something similar) since its inception two years ago. I
>> attended ScrumMaster training last June, and most of its content was quite
>> familiar to me, "scrum of scrums" being one of the notable exceptions. I
>> really liked the idea and immediately thought that it's something that we
>> should consider implementing. However, I have several comments about this:
>>
>> 0. As other people said already, not all the teams in the Foundation
>> practice Scrum, and even those that do, do it quite differently, so making
>> sure that everyone is on the same page—or rather, in the same book—will be
>> a challenge.
>>
>> 1. Teams need Stuff from each other in different scopes. Some needs are
>> immediate for the current sprint, for example: "I need somebody from
>> Platform to review a commit, because otherwise the team won't be able to
>> complete story #1234 in its current sprint." Some needs are less immediate,
>> but relate to something in the Product Backlog, for example: "I need Mobile
>> to change some things in ResourceLoader support in MobileFrontend, so that
>> my team will be able to start working on story #2345 in one of its next
>> sprints". Is Scrum of Scrums for both types of needs or only for one of
>> them? Can be both, but this must be properly defined; for future sprint
>> needs, the Product Owners must be involved, because they set the priorities
>> for them.
>>
>> 2. Please, oh please, let's make sure that these meetings are not like
>> the weekly Features team meeting in which I used to participate before
>> Language Engineering was separated from Features. They were very long, and
>> contained just about updates on the work, and much of them was not so
>> relevant (I don't know how are these meetings held now, if at all). Most
>> importantly, they must be properly time-boxed, and the participants should
>> prepare the Needs section well: To know what are they going to ask from
>> other teams and to emphasize properly. Scrum is about removing blockers, so
>> this section is supposed to be the most important.
>>
>>
>> --
>> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
>> http://aharoni.wordpress.com
>> ‪“We're living in pieces,
>> I want to live in peace.” – T. Moore‬
>>
>>
>> 2013/9/18 Erik Moeller <erik at wikimedia.org>
>>
>>> Hi folks,
>>>
>>> at the engineering management level we've been talking about how we
>>> can improve inter-team coordination/prioritization decisions without
>>> managers attempting to continually run interference on behalf of teams
>>> (which is a recipe for failure, IMO, because managers generally are
>>> not nearly sufficiently involved in the day-to-day workings of a
>>> team).
>>>
>>> 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")
>>>
>>> One process recommended by scrum practitioners is a scrum of scrums.
>>> The idea is that one representative of each team meets with other team
>>> reps for a daily (or 3 times/week, or whatever works) 15 minute
>>> coordination sync-up, similar to the daily stand-up but focused on
>>> inter-team issues and blockers. The process is described here:
>>>
>>>
>>> http://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meeting
>>>
>>> This particular article recommends having implementers (devs/testers)
>>> attend the scrum of scrums. Product owners, ScurmMasters and others
>>> can get involved when there's a conflict around prioritization or
>>> blockers that need to be resolved. But having implementers attend the
>>> scrum of scrums can help keep the meeting focused on technical
>>> details.
>>>
>>> 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.
>>>
>>> Thoughts on the general concept?
>>>
>>> Thanks,
>>> Erik
>>> --
>>> Erik Möller
>>> VP of Engineering and Product Development, Wikimedia Foundation
>>>
>>> _______________________________________________
>>> teampractices mailing list
>>> teampractices at lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>>
>>
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20130923/76f4318c/attachment.html>