[teampractices] [Engineering] Feedback requested on proposal for creation of Agile Specialist Group

Tue Mar 4 22:54:00 UTC 2014

PS Whoever comes up with a cogent tl;dr version of my most recent email
before I get around to it, I'll buy you dinner next time I see you.

On Tue, Mar 4, 2014 at 3:45 PM, Arthur Richards <arichards at wikimedia.org>wrote:

> Thank you everyone for your feedback - on the list, on the talk page, and
> personally. There is *a lot* here, so I am going to try and respond to as
> much of it as I can in one fell swoop. If you read all the way to the end,
> I'll owe you a beer (or equivalent).
>
> Note that I am going to use the word 'scrummaster' a lot in here. Every
> time I say 'scrummaster', think 'agile specialist' (in the lingo of the
> proposal), or 'scrummaster (or similar)' to account for teams that do not
> practice Scrum but have someone operating in a role similar to that of
> a scrummaster.
>
> Two of the central themes I am seeing emerge from all the feedback are
> questions around need and value. Do we really NEED what we are proposing?
> Is the VALUE of what we are proposing worth the cost?
>
> There is already a very clear need for each of the services offered by the
> proposed ASG, which I'll describe per proposed service offered - this will
> hopefully also clarify the value of what we are proposing:
>
> 1) Providing dedicated resourcing for a team's scrum aster (or similar)
> role:
> As Erik pointed out, within minutes of sending out this proposal there
> were three teams requesting this service. Oliver asked, 'Everyone so far
> seems to be saying "we don't have enough resourcing on our team to be
> scrumming as well as engineering" - not "we don't know how" but "we have
> too much crap to do". So is the answer advisors, or just hiring engineers
> for the teams that need them with a focus in the JDs and interview
> processes on people with scrum experience willing to take up being a scrum
> master as a primary duty?' There are a few reasons I can think of as to why
> one of these teams wouldn't want to hire another person to fulfill this
> role, or perhaps can't hire another person to fulfill this role: hiring is
> hard and time consuming, maybe the team/dept is budget-strapped, maybe the
> team is overburdened already and being responsible for bootstrapping
> someone new is too much overhead, maybe the team is too small to require a
> full-time scrummaster, maybe the team  just doesn't want to deal with it
> for whatever reason but recognizes that it would be beneficial to
> have someone around to facilitate the team's process and its continual
> improvement.
>
> More importantly, leaving it entirely up to the individual teams to
> fulfill this need perpetuates the current paradigm, which I think needs
> serious improvement. I have been operating in a scrum master role at the
> WMF longer than anyone else (I think - I'm pretty sure I was the first). I
> have been closely involved in the evolution of agile practices generally at
> the WMF. I have facilitated the adoption of Scrum (or something close to
> it) with three teams, and have been involved in various capacities with
> other agile teams at the WMF at various points in their evolutions. It's
> been really awesome to be a part of. But there is one thing in particular
> that I think is holding very agile team at the WMF back: there is no
> institutional support for people working in the scrum master role. Most of
> these folks are engineers who report to engineering directors, some are
> product managers who report to the director of product. There is very
> little unity across this peer group. There is no clear structure for
> support, career development, or even a clear career path at the WMF. This
> means that, in essence, every scrum master operates almost entirely within
> the vacuum of their own team.
>
> We have tried to combat this informally amongst ourselves, but our efforts
> have largely failed - I believe due to the fact that they are informal
> and ad hoc. It's easy to skip out on, say, a periodic scrum master meetup
> when your workload and team obligations are pressing down on you. Imagine
> if this was also the scenario for designers or product managers. Imagine
> the lack of support designers and PMs would have, the disunity between
> teams, difficulty of collaboration, the dearth of peer support, and
> difficulty of professional enrichment/advancement. That is the current
> scenario for scrummasters.
>
> 2) Periodic or one-off collaborative engagements to facilitate process
> improvements for individuals and teams:
> The obvious need here is demonstrated by the periodic and ongoing
> engagements that various engineering teams have or had with Thoughtworks,
> as well as the large trainings/workshops that Tomasz and I have conducted
> with Core Features, Mobile Apps, and Wikipedia Zero. There is also another
> side to this that may not be particularly visible to everyone in
> engineering: I and others have been solicited to help different teams
> figure out how to resolve acute issues.
>
> Subbu asked 'So, let us say 20 teams decide to adopt scrum methodology and
> say, they need 1 day of training a quarter for the first year -- that is
> still only 80 days of work for that year (I totally made up these numbers)
> even if 2 people are needed to do this. Does scrum require ongoing training
> that is more frequent and that goes beyond the first year?' The
> short answer here is Scrum doesn't really require any training per se. But
> I think the heart of this question is 'Once engineers/teams go through a
> training, do they need more training?' A huge component of the larger
> trainings that we've done (jumpstarting the Core Features team with Scrum,
> for instance) is getting the team on the same page, discovering where they
> are/have been facing real problems, facilitating the team to begin to
> figure out how to resolve them. Scrum, and an agile mindset more broadly,
> is not a one-size-fits-all thing. At the heart of all of this is helping
> teams and individuals not only understand where they may be dysfunctional,
> but also helping them figure out how to solve the problems themselves.
> Personally, I think these large-scale trainings should happen as often as a
> team wants them. They are particularly valuable when a team kicks off an
> entirely new project, or when team membership has changed. Long story
> short, these 'trainings' are not fire-and-forget events. Further,
> workshops/trainings/etc should really be tailored to the specific needs of
> the individual teams. If there's a workshop happening with a mature Scrum
> team for instance, I wouldn't bother spending time on defining
> what 'iterations' and 'backlogs' are or how to run a daily standup meeting.
>
> The one-off engagements I think are very much in the same vein. It all
> comes down to what, specifically, the team wants and needs. I am not sure
> of the current frequency of small engagements or all-out
> workshops/trainings at the WMF right now, but I know that I have had to
> turn down requests to conduct both because they are incredibly time
> consuming, and my primary responsibility is to the mobile web team.
>
> One response to this may be "well, we've been using Thoughtworks for this
> kind of stuff in the past, why don't we just keep doing that? That way, we
> don't have to be bothered". While the Thoughtworks trainings I have been a
> part of have generally been really good and of high quality, any of you who
> have been through the Thoughtworks trainings can probably think of a few
> reasons why this might not be a great option. The TW trainings are
> generally pretty boilerplate, rarely directly address or clearly take into
> consideration the nature of our work (community driven, open source), have
> yet to coherently address distributed teams, and it's hard to shake the
> feeling that they are outsiders who don't really get us. Further, relying
> on a third party for this stuff is not sustainable, and I would argue is
> not cost effective (they are *very* expensive - however I do not have
> numbers to directly compare the cost of our proposal vs TW engagements).
> There are a few of us in the org who are deeply passionate about process
> (believe or not) and particularly about figuring out how to improve our
> ways of doing things with intimate knowledge of the context in which we
> work. If we can continue building and strengthening our skillsets and
> become self-sufficient in this area, then we are deepening and
> strengthening our capacity not just as an engineer organization, but as a
> community more broadly. Personally, I would rather see the WMF invest money
> directly into strengthening its community in this way than paying an
> outside entity in perpetuity.
>
> 3) Mentorship and support for people in the scrum master (or similar) role
> I mostly addressed this in response to #1 above. The important thing to
> note here is that we do not want the ASG to become a monolithic group
> dictating how to do things to all of the engineering teams at the WMF. If
> an engineering team wants to house their own scrum master, more power to
> them. But we also want to make sure that *anyone* operating in this role
> can benefit from institutional support and clear paths for professional
> development and advancement. If the ASG comes to pass and is successful, I
> can imagine a future where the ASG naturally houses all of the scrum
> masters. But until that happens, or if it never happens, I want to make
> sure that anyone who wears the hat can benefit from as much of the same
> structural support that those in the ASG as possible.
>
> Overall, fulfilling all three of these services is a HUGE amount of work.
> Trust me, I have been doing all three of these for a while now as much as I
> possibly can :)
>
> Still not convinced about whether or not this stuff is really NEEDED? If
> you really believe that the teams who have already embraced these ways of
> doing things are not in a better position and delivering more value (both
> to our users as well as the team members themselves), or that the org as a
> whole is not a better place as a result, then this is a pointless debate.
> Personally, I believe deeply, with great conviction, that we are in a
> *much* better place as a result of all of this than when I started at the
> WMF nearly 4 years ago. I think we have a long way to go, and indeed will
> have eternal room for improvement. I am confident that continuing our
> trajectory and embracing the proposal for the ASG will make us stronger and
> help us get there faster.
>
>
>
> On Tue, Mar 4, 2014 at 12:15 AM, Keegan Peterzell <
> kpeterzell at wikimedia.org> wrote:
>
>> On Tue, Mar 4, 2014 at 12:46 AM, Erik Moeller <erik at wikimedia.org> wrote:
>>>
>>> In any case, the WMF engineering@ list covers the entire
>>> engineering/product department and has generally been an inclusive
>>> place where non-technical participation is welcome. We also created
>>> the teampractices@ list (public & open) as a more focused place for
>>> these kinds of conversations about, well, team practices, and this
>>> thread was copied to that list as well.
>>
>>
>> Awesome. I did not know about this new list.
>>
>> <  https://lists.wikimedia.org/mailman/listinfo/teampractices >
>>
>> Thanks to those involved in creating it :)
>>
>>
>> --
>> Keegan Peterzell
>> Community Liaison, Product
>> Wikimedia Foundation
>>
>> _______________________________________________
>> 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
>

-- 
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/20140304/75516196/attachment-0001.html>