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

Tue Mar 4 22:45:07 UTC 2014

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