Team Practices Group/Proposal for formation

Jump to navigation Jump to search

We propose the creation of an Team Practices Group (TPG; formerly Agile Specialist Group or ASG) that focuses on supporting the Wikimedia Foundation's engineering teams to embrace and evolve their agile practices. This proposal seeks to institutionalize and make scalable previous work done by Tomasz Finc and Arthur Richards on trainings, mentorship, and support for new and existing agile teams.

What will the TPG do and how will it impact other teams?[edit]

The TPG will offer the following services to all WMF engineering teams:

  • Providing dedicated resourcing for a team's scrummaster (or similar) role, depending on availability/resourcing of the TPG.
    • e.g. A team wants a dedicated scrummaster but does not currently have anyone on their team who wants or is able to take on the role. They go to the TPG, and the TPG provides them with someone who can fulfill that role.
  • Periodic or one-off collaborative engagements to facilitate process improvements for individuals and teams
    • e.g. A team getting ready to kick off a big project wants help in reorganizing their team practices to use the Scrum framework. They request support from the TPG, and the TPG provides Scrum training to that team.
  • Mentorship and support for people in the scrummaster (or similar) role.
    • e.g. An existing scrummaster (not provided by the TPG) is looking for ways to increase and improve their skills. S/he requests support from the TPG, and the TPG provides mentorship and resources.

Engagement with the TPG is entirely optional for WMF engineering teams. Engineering teams may elect to receive all, some, or none of the TPG services at any given time.

The TPG will not be prescriptive nor dogmatic. The TPG will be agnostic in regards to specific agile methodologies (e.g. Scrum vs Kanban). Instead, the TPG will work with individuals and teams to facilitate their discovery and implementation of methodologies/approaches work best for them, guided by the agile manifesto and agile principles.

Resourcing, growth, and budget[edit]

To mitigate some of the risks of introducing a new group like this and in order to facilitate its success, the TPG will be built out iteratively with an eye towards continual improvement.

During its first two quarters, the TPG will be staffed by the group’s head and 2 agile specialists. Agile specialists will be responsible for supporting mentorship and training activities, as well as acting in a scrummaster (or similar) role for 1-2 teams (depending on team and specialist maturity). Provided that the approach and purview of the group is deemed sound, the TPG would hire 2 additional specialists over the third and fourth quarters of existence. Assuming the group meets with success, the group would then be in a solid position to continue scaling to meet the needs of the WMF engineering department.

Budget will be required for staffing, 1-3 in-house trainings per quarter (including travel, training supplies, food, etc.), and external trainings/certifications for the group’s staff (eg Scrummaster certification, etc).


This proposal is modeled off of the Wikimedia Foundation’s real-world experiences of what has worked and what has not, as well as from learned best practices of other successful organizations engaged in agile software development, such as ThoughtWorks and Spotify. [1].

To date WMF engineering teams have depended on two sources for process coaching:

First, we contracted with ThoughtWorks to bring in agile consultants for teams including Fundraising, E3, Mobile Web, and others. This had the advantage of not taking any WMF staff time for facilitation, bringing in external ideas, and bootstrapping some of our most successful teams. The downside of this approach was that the instruction felt very distant from day-to-day realities at the WMF. It lacked coverage of integrating remote employees, provided little to no perspective on community inclusion and management, seemed tinged with a corporate perspective, and generally felt pushed onto participating teams.

Reacting to this, both Tomasz Finc and Arthur Richards started conducting internal trainings for teams like Core Features, Mobile Apps, and others while providing periodic coaching for the Language team. This had the advantage of providing a WMF-centric perspective, keeping and evolving knowledge in-house, engendering a greater degree of trust amongst the teams, and building a stronger sense of collaboration and unity. However, this approach has negatively impacted Tomasz and Arthur’s other existing responsibilities and has provided little room for followup or improvement, highlighting that this approach is not scalable.

Given the needs of existing agile teams and the growing popularity of embracing an agile software development at the WMF, these approaches for process improvements are inadequate. In addition, people currently working in the scrummaster (or similar) role have been seeking greater institutional support. At Wikimania 2013, they opted to create a mailing list and conduct regular meet ups to informally support one another. However, due to the ad-hoc nature of this group and the informality of the meetups, meetup attendance has waned while demand for greater structured support and mentorship continues to grow.

The TPG will rectify these inadequacies while also providing much needed support and a new career path for process leaders at the WMF. Fueled by our own experiences and the influence of other successful agile organizations, the TPG will provide crucial resources and services to WMF engineering to facilitate more sustainable productivity while also strengthening our internal bonds of collaboration and community. We look forward to engaging with the engineering community in discussing this proposal.


  1. Spotify in particular has scaled their agile software development processes to dozens of teams, spread out around the world. While their products differ greatly from ours, the WMF shares many of the challenges they have faced in regards to scaling collaborative development practices. Their structural approach to scaling agile organically while embracing fast-paced continual improvement at every level of their engineering organization has greatly influenced our approach to evolving our teams’ processes as well as how we envision the ACO and agile more broadly at the WMF. For more info, see 'Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds'