Team Practices Group/2016-04-05 Language

Runa, Kristen, Joel

Context: Amir talked to Joel previously about TPG helping Language team make tweaks to their practices.

Runa: There are some special bits in how the team operates as opposed to other teams.

Runa's goals for this meeting:

What suggestions does TPG have, taking into account Language team's special circumstances? For how we can get to the next level of maturity in our processes, and suggestions around the delivery process around how we do rollout planning. Been following VE rollout, handling the complications with users, wikis, etc, wanted to have that as a secondary discussion, on how to get the rollout plans for some of our projects coming up.

Context of Language Team development processes
Team is 5 years old, some processes not mature, haphazard. Multiple projects at once, not one project like VE or Multimedia team, at least two or three projects in development at once. Around then, Scrum processes were somewhat false: no clear understanding of how to assign points, mixed group (developers, UI specialists, communications), not purely development, can't make uniform decisions of level of development effort, so points system was being done in an artificial way, generating resistance. Ca. 2013, got some observers, including Arthur, then got a coach for nearly 6 months. Also team churn and leadership change; I was a ScrumMaster. Because content translation was just starting, coach suggested form Scrum process around Content Translation. Make release plan, sprint plans; formed some practices around that, not very watertight but served the purpose and joint effort within team. Did away with points, started grouping tasks into sprint boards, did have some overflow, didn't finish everything in one sprint. Reduced that, but never a perfect fit. Problem we have is that as opposed to conventional companies, we have a mix of development, support, and support engineering team, creating new products that in a conventional team would maybe be created by a completely separate team, and we are also doing engineering support, responding to queries and support. Have a response plan with 2-day response for Content Translation, get fixed planned into sprints. Sprint always has planned and unplanned tasks. And that will continue, have two other projects heavily used on wikimedia sites, and there are additional projects, more upstream (i18n used by other software developers).

Now trying to be more conservative, but that reduces our velocity. And we don't have enough people to make a more ... plan. We have some individuals that are not very committed to Scrum practices, would rather use it as a to-do list. Our releases are always aligned to the quarter. Strong resistance to doing points or other extra effort.

Joel's summary/feedback
1) team is not pure dev, has a mix of devops, and a support commitment leading to constant interruption

2) understaffed relative to goals

3) team members are resistent to overheard

And not finishing everything in a sprint, why is that a problem? Runa: signal that we are behind; if we have 60% of our capacity set aside for interruptions, means our planned capacity is going down. If we go for a lower amount of planned work to prevent not finishing everything, slows our velocity. J: is this an issue of overall capacity, or that planning limitations lead to inefficient work? Runa: We reserve space for interruptions, so we end up with 120% commitment.

Kristen: What brought you to Scrum? Runa: It was there already by the time I arrived. maybe a management decision. Issue of doing points, measuring level of effort, threw that process out of the window. Kristen: are there parts that have been working really well for you? Runa: Yes, process around content translation -- we did not do product planning before [the coach], we ended up with a long list of things that could be done during the year, without parameters around individual products, always a tendency to creep through things: we have reduced this tendency. And now we are not thinking more than 3 months of development work ahead, aligned to quarters, based on that we can determine our tickets, using Phabricator pretty well. J: what is the benefit of that? It's easier for us to identify the goals, align tickets, more measurable for us.

J: What would you want to get out of a TPG engagement?

Runa: Amir mentioned some improvement in our processes, I'll check back again with him.

Next steps:
Runa to check with Amir about a next meeting; Amir will be in India for that. Joel is unavailable next W/Th/Fr. suggest 1 hour, next Tuesday.