<div dir="ltr">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 :)<div>
<div><br></div><div>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.</div></div><div><br>
</div><div>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.</div>
<div><br></div><div>-Toby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 21, 2013 at 11:38 AM, Amir E. Aharoni <span dir="ltr"><<a href="mailto:amir.aharoni@mail.huji.ac.il" target="_blank">amir.aharoni@mail.huji.ac.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr">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:<br><br></div><div dir="ltr">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.<br>
<br></div><div dir="ltr">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.<br>
<br></div><div dir="ltr">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.<br>
</div></div><div class="gmail_extra"><div class="im"><br clear="all"><div><br>--<br>Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי<br><a href="http://aharoni.wordpress.com" target="_blank">http://aharoni.wordpress.com</a><br>
“We're living in pieces,<br>
I want to live in peace.” – T. Moore</div>
<br><br></div><div><div class="h5"><div class="gmail_quote"><div dir="ltr">2013/9/18 Erik Moeller <span dir="ltr"><<a href="mailto:erik@wikimedia.org" target="_blank">erik@wikimedia.org</a>></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks,<br>
<br>
at the engineering management level we've been talking about how we<br>
can improve inter-team coordination/prioritization decisions without<br>
managers attempting to continually run interference on behalf of teams<br>
(which is a recipe for failure, IMO, because managers generally are<br>
not nearly sufficiently involved in the day-to-day workings of a<br>
team).<br>
<br>
Examples of problems that I think are worth solving:<br>
- Ensuring platform and ops are in the loop on the latest shiny<br>
features you're building<br>
- Surfacing perceived blockers ("we're still waiting on the Varnish<br>
migration til we can release X, so we've moved on to Y")<br>
- Ensuring feature developers are in the loop on new services/APIs<br>
that are being built that can be used by feature devs<br>
- Surfacing questions about prioritization ("Ops: we've been asked to<br>
work on OSM" - "Mobile: we should probably talk to the mobile PM to<br>
figure out how urgent that is")<br>
<br>
One process recommended by scrum practitioners is a scrum of scrums.<br>
The idea is that one representative of each team meets with other team<br>
reps for a daily (or 3 times/week, or whatever works) 15 minute<br>
coordination sync-up, similar to the daily stand-up but focused on<br>
inter-team issues and blockers. The process is described here:<br>
<br>
<a href="http://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meeting" target="_blank">http://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meeting</a><br>
<br>
This particular article recommends having implementers (devs/testers)<br>
attend the scrum of scrums. Product owners, ScurmMasters and others<br>
can get involved when there's a conflict around prioritization or<br>
blockers that need to be resolved. But having implementers attend the<br>
scrum of scrums can help keep the meeting focused on technical<br>
details.<br>
<br>
In our context, this may be the kind of meeting where note-taking<br>
would be useful. For example, a daily email to engineering@ including<br>
the notes could be helpful. But that's just an idea.<br>
<br>
Thoughts on the general concept?<br>
<br>
Thanks,<br>
Erik<br>
<span><font color="#888888">--<br>
Erik Möller<br>
VP of Engineering and Product Development, Wikimedia Foundation<br>
<br>
_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
</font></span></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>