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 <aricha...@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 < > kpeterz...@wikimedia.org> wrote: > >> On Tue, Mar 4, 2014 at 12:46 AM, Erik Moeller <e...@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@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
_______________________________________________ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
