[teampractices] Scrum of scrums

[Toby Negrin]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20130922/77f40750/attachment.html>