Recently, the Wikimedia Foundation’s mobile web engineering team underwent a rapid change, more than doubling the number of engineers on the team within a period of four weeks. While this change was eagerly anticipated, the team size increase had unanticipated impacts on our team process and communication. It quickly became obvious that our new team size was making our usual way of working unsustainable.
In many organizations, the inclination might be to automatically split the team in two. However, the mobile web team operates with agility in mind, embracing the principle that “the best architectures, requirements, and designs emerge from self-organizing teams” [1]. Rather than telling the team that they would be split up, it was assumed that “If the team is to be trusted with solving the problem of how to build the product, it seems appropriate to trust it with the decision about how to structure itself to do so.” [2]
In this blog post, I will share the challenges that arose when the team grew, and the experiment that we designed to address these challenges.
Big Team Challenges
| Velocity The team uses a framework called Scrum to coordinate their work and continuously improve. One metric used in scrum is known as the team’s “velocity”, a measure of how much work the team can do within a timeboxed development cycle. Measuring and tracking velocity can provide clues about what is happening on the team. A team may see their velocity decreasing over a couple of development cycles, and discover that a member has other obligations pulling them away from the work that was planned. In the case of the mobile web team, our velocity shot up. While this is “a good problem to have”, we now know that a sharp increase in velocity comes with its own set of challenges. Being observant about changes and trends in velocity can help a team catch problems early and course correct. |
As the team prepared onboarding tasks for our new members, we anticipated that it would take the better part of a quarter for new team members to get up to speed. Little did we know that our new team members were actually HUNGRY CODE MONSTERS that would chew through our backlog of work in their first couple of development cycles. While we were rejoicing over our awesome new team members, we also came face to face with a unique and puzzling problem: we ran out of work to do.
By “running out of work to do”, I don’t actually mean that there was nothing for the team to work on. There is always plenty of stuff to work on: code cleanup, low-hanging feature requests, bugs, UI standardization work, helping out other teams, and so on. But as an agile team, our mandate is not just to do whatever work is possible, but to deliver the highest value features to our users at any given point in our development cycle. Working in this way requires a vigilant product owner who is in touch with user needs and always thinking about what the highest priority is at any point in the product life cycle. Under the guidance of our product owner, every two weeks the team meets and carefully considers and plans the work that will deliver the most value for our users. But… there are only so many waking hours in a product owner’s day. With our newly expanded team (lovingly nicknamed “MegaTeam”), the burden of maintaining a well-scoped and prioritized backlog of work suddenly became a lot more challenging, as our pace of working quickly outpaced our capacity to specify the next features to be developed.
Further burden was placed on our tech lead, whose role on our team is to give input on technical considerations of our work so that the team is able to estimate it. More of our tech lead’s time was taken away from coding and diverted towards fleshing out new work. Team members from Design and Analytics also felt the impact. All of a sudden we needed mockups or data analysis at a faster rate than before. The impact of our higher velocity (see sidebar) on our product owner, tech lead, and other team members was one of the first indications that our usual way of working may not be sustainable.
| More meetings? Or more freedom…? A little bit of up-front meeting time every couple of weeks can save hours of waste and confusion. After a one-hour estimation meeting, and a few days later, a short kickoff meeting development cycle, the mobile web team has a two-week uninterrupted stretch of time to focus on the work that they committed to. The one exception is an alternate day fifteen minute standup meeting for the team to coordinate their daily work. This short meeting is a quick and easy way to avoid duplication of effort, help unblock other team members by pointing them to helpful information, and otherwise avoid stepping on each other’s toes. At the end of the cycle, a retrospective meeting allows the team to pause and take stock of how things are going, catching pain points before they turn into dysfunctions, as well as celebrate what went well during the past two weeks. Within these lightweight boundaries, there is room to experiment, innovate, reflect, self-organize, and learn. |
Another symptom of our growing pains manifested in our meetings. As a Scrum team, we have a preset schedule of goal-oriented meetings (see sidebar). These meetings are strictly timeboxed to keep the focus tight and the meetings efficient. Where we previously had established a regular and sustainable cadence for planning and working, with our new larger team we were now unable to complete our meeting objectives in the allotted times. When timeboxes run over and planning becomes challenging, it can be another indicator that the state of the team is not sustainable.
As the team became larger, communication overhead also increased. Even with a well-organized issue tracking system, people were still wary of stepping on each other’s toes and not always sure what the right thing to be doing was. Coupling that with the fact that we were working in new territory (Wikidata!) and learning as we went, things began to feel chaotic; not quite emergency status, but, as our Product Owner put it, maybe time for a Pan-pan.
The Experiment
When it started to become obvious where our pain points were, we decided to hold a special retrospective meeting to focus on the issues we were having as a megateam. A retrospective is an opportunity for a team to reflect on what is working well, what is not working well, and what they want to improve, and a practice that the mobile web team does regularly.
For this particular retrospective, we reviewed a list of observations about what had been happening as our team had grown, and did a one-word check-in [3] to get a sense of people’s reactions to the events of the past few weeks. We then spent some time diving deeper into analyzing what had been occurring, and listing possible next steps to mitigate our problems.
One of these possible next steps was to split the team into two teams. In the course of discussion, the notion of a hard split vs a soft split emerged. The hard split would be two different teams with separate work backlogs, planning meetings, and issue tracking. The soft split would keep some parts of our current process intact, like team standups and planning meetings, but introduce a new additional backlog of work that team members could organize around and draw from. We decided to try a soft split as an experiment, and see what the impact would be on our megateam problems. Our theory was that a separate backlog and backlog owner would relieve some of the pressure of having to scope out work at a faster than humanly possible rate, give our fast-working team an alternative stream of work to draw from, and perhaps lessen some of our coordination problems by having two distinct focus areas. We identified a body of work that would comprise our new, second backlog, generally focused on making our codebase easier for new contributors to work on. We captured this work in a new backlog, and designated an owner for the backlog. We set up some working guidelines around the practical aspects of planning and working (e.g. when and how the team would groom and work on the new backlog, who should be involved, and what to do in the case of conflicts between the two backlogs). We set goals and a timeline for trying out this new dual backlog approach, and started our experiment at the beginning of the next development cycle.
What’s Next?
| Working in short cycles By working in short cycles and inspecting and adapting regularly, we create conditions where we can fail and learn quickly, and apply our learnings. Perhaps a feature developed during a two-week sprint has not proven popular with users, or an insurmountable technical problem was discovered while working on a task, revealing that it doesn’t make business sense to continue the work. If an “experiment” fails, it can be hard to feel like you’re throwing work away, but if the time invested is a couple of days during a two-week cycle rather than the hundreds or thousands of hours one might put in to a longer, non-iterative project, the overall risk and investment is much lower. |
Our experiment is still in progress and we are learning along the way. We decided to run the experiment over two full development cycles (see sidebar) and revisit it at the beginning of the new year. As we approach Q3, mobile reader engagement features are coming into focus, and we’ve received the call to “double down” on mobile efforts. While we still don’t know if our experiment will be a success and how our work might change in the coming quarter, the mobile web team has already exhibited agility in the face of uncertainty and change, which will surely serve us well in the months to come.
In the meantime, we’ll keep our eye on our current experiment and keep learning from it. Find out what happens next in Part II of The Adventures of MegaTeam, coming in early 2015!
Kristen Lans, WMF Team Practices Group, Mobile Web and App Team ScrumMaster
References
- ↑ Beck, Kent; et al. (2001). “Manifesto for Agile Software Development”. Retrieved 14 June 2010.
- ↑ Cohn, Mike. 2010. Succeeding with Agile: software development using Scrum. Upper Saddle River, NJ: Addison-Wesley, p.188
- ↑ Derby, Esther, Diana Larsen, and Ken Schwaber. Agile retrospectives: Making good teams great. Raleigh, NC: Pragmatic Bookshelf, 2006, p.40
Can you help us translate this article?
In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?
Start translation