[teampractices] Scrum of scrums

Mon Sep 23 23:26:13 UTC 2013

Hi Arthur -- FWIW -- I signed up to get this going (among the Engineering
directors)

Want to chat briefly tomorrow about getting this going?

-Toby

On Mon, Sep 23, 2013 at 4:23 PM, Arthur Richards <arichards at wikimedia.org>wrote:

> 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
>
> _______________________________________________
> 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/20130923/6115a261/attachment-0001.html>