Open and agile?

Facilitating openness and including volunteers in agile sprints

This post is based on a discussion at the Mozilla All-Hands event in December 2016. Participants in that discussion included Janet Swisher, Chris Mills, Noah Y, Alex Gibson, Jeremie Patonnier, Elio Qoshi, Sebastian Zartner, Eric Shepherd, Julien G, Xie Wensheng, and others.

For most of 2016, the Mozilla marketing organization has been moving towards working agile — much of our work now happens within “sprints” lasting around 2.5 weeks, resulting in better prioritization and flexibility, among other things. (For those familiar with agile software development, agile marketing applies similar principles and workflows to marketing. Read the Agile Marketing Manifesto for more background.)

However, one aspect of our work that has suffered in this new paradigm is openness and inclusion of our volunteer community in marketing activities. While the agile workflow encourages accountability for full-time team members, it leaves very little space for part-time or occasional participation by volunteers. We are Mozilla, and transparency, openness, and participation are part of our core values. This disconnect is a problem.

This post explores the issues we’ve found, and shares some potential solutions that we could work towards implementing.

The problem

Since moving to an agile, “durable team” model, the amount of interaction we have had with our volunteer community has decreased. This is written from the perspective of the Mozilla Developer Network (MDN) team, but we are sure that other teams have experienced similar negative trends.

The main reasons for this decrease are:

• The tools used to track work are not open, so volunteers cannot access them.
• The agile process in general does not lend itself well to volunteer discovery or contribution. Their work is deprioritized, they feel ignored, they find it harder to participate.
• There is very little information provided for volunteers who want to participate in a project managed in an agile fashion.

The challenge we face is how to make the agile process more transparent, so that volunteers can understand what is happening and how it happens; more open so that volunteers can contribute in meaningful ways; and more welcoming so that volunteers feel they are part of a team and are appreciated and recognized for their efforts.

Solutions

Let’s look at the solutions that were discussed. These details are fairly brief, but they act as good starting points for further investigation.

Openness of tools

We need to review the tools we are using, and make sure that they are open for volunteers to get information and updates. For example:

• Slack is hard in terms of giving people the right permissions.
• Some of the “agile tools” can appear closed off and difficult to access for those outside your organization (at least, in the ways we’ve been using them).

We need to work out better tools/workflows for volunteer contributions.

Information

An explainer doc to explain the agile process would be useful, including:

• How the process works in general, and an explanation of key terms like durable team, “functional team”, “cross-functional”, etc.
• What the different teams are and what they are responsible for.
• How to find more information on what you can do for each team at the current time and in the future.
• How you can contact each team and get updates on their work.

There is some information that already exists — an explanation of MDN’s agile process, and a glossary of agile terminology.

When questions are asked, it would be good to make sure that we not only answer them on a public list, but also document the answers to make them easy to find for others.

When decisions are made, they need to be clearly communicated on the public list for the agile team it relates to.

Including volunteers

To participate in an agile team, volunteers need:

• Access to tools and information, so they can do work and communicate with agile teams.
• Access to lists of “low hanging fruit” tasks related to the team’s work that they can pick up and work on.
• A chance for inclusion in the conversation, whether synchronously or asynchronously.

To achieve this, we need to:

1. Review our tools, and make sure they can be made open to volunteers.
2. Make information available, as described in the previous section.
3. Make lists of tasks that volunteers can do in each agile team easily available. To achieve this, one suggestion is to share Epics with volunteers (don’t overwhelm them upfront with too much detail), but make lists of tasks available on the epic pages, along with who to contact about each task.
4. Make it clear how you can communicate with agile teams — a clear mailing list and IRC/slack channel would be the minimum.
5. Keep an open dialog going with our community:
   • Open up planning meetings to allow volunteers to take part in the planning.
   • Say what we are working on next before the sprint starts and what work volunteers can do.
   • Say how things are going during the sprint, and what help we need at each stage.
   • Report on how things went at the end of the sprint.
6. Make meetings (standups, mid-sprint review, post mortem, etc.) more useful.
   • Include an IRC channel running at the same time, for further communication and to provide notes that people can read afterwards.
   • Allow people to talk about other subjects in meetings, to make them more human.
   • Sometimes conversation can be monotonous (e.g. “I’m still working on the same task” for 5 days running). If this is the case, use the time more usefully.
   • Use the meetings as an opportunity to update volunteer asks; if we find we need more help than we initially thought, do a shout out to the community.
   • Consider office hours for agile teams (whether in Vidyo, IRC, etc.), so team members and volunteers alike can drop in and talk.
   • Record video meetings so others can benefit from them asynchronously.

We ought to fit communication with the community/volunteers into each agile meeting, as a recurring agenda item.

Further points

1. Make sure there is always someone present to help volunteers with questions they have, all the way through a sprint. Keep communication public; don’t let conversations happen in private, then risk the team member going on holiday or something.
2. We should relax a little on the agile principles/processes — use them where they are useful, but don’t stick to the letter of the law for the sake of it, when it isn’t helpful. As an example, the MDN durable team has gone from everyone having a standup every day, to two standups per week for the writers, and two standups per week for the developers. We found anything more to be too high-frequency, and a waste of time.
3. One situation that might make using open tools difficult is if any of the work is sensitive, e.g., discusses security issues. We could get around this by dealing with such issues inside private bugs on Bugzilla.

Next steps

We want to get feedback on this, and hear about other people’s pain points and solutions or insights for working open inside agile teams. If you have any other thoughts about how the process could be improved, please do share!

After that, we want to distill this information down in a set of documentation to help everyone in marketing (Mozilla, or otherwise) to be open while working in an agile form.