[teampractices] Scrum of scrums

[Amir E. Aharoni]

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