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.

31 responses

  1. Vivek Kumar wrote on :

    I really like the idea of transparency. Although I am not contributing to Mozilla but this article has instigated me to be a part of our open Mozilla environment.
    Keep up the good work. Cheers!

    1. Chris Mills wrote on :

      Thanks! Please get in contact if you want to contribute.

  2. Medusa Development wrote on :

    Hi Chris,

    As a developer that has written ridiculous numbers of C++ class libraries, I have several ideas on how to make the code base simpler to work with for developers.

    One quick suggestion is to make mozilla itself the development environment for mozilla (you know, the compiler compiles itself).

    Medusa Development

    BTW — I use mozilla for my development with a web-based IDE of my own creation.

    1. Chris Mills wrote on :

      Great! A good place to share such ideas would be the dev-platform mailing list: https://lists.mozilla.org/listinfo/dev-platform

  3. Deep purohit wrote on :

    Ive not contributed to Mozilla till now, but always wanted too.
    Considering the agile process, if there is any task, which i can complete in my spare time (which can vary day to day basis) i would not like it to be sprint bound.
    Somedays i can do more, and some days i dont even get time to think about it.
    So, a system which do not restrict me with strict estimates; i would like some part of it open ended.
    Cheers and kudos for your thinking and good work.

    1. Chris Mills wrote on :

      This is a really good point – sprints tend to be all about tight timescales, which are often at odds with volunteer work. I’m very interested in exploring how this issue can be mitigated.

  4. Brian wrote on :

    I went through the process of logging an issue about an MDN Learn Article. It was fixed, and I was in discussion with the author, but the logging tools seemed a little archaic in comparison to Jira, especially considering all the effort Mozilla puts into UX for their end users.

    I wasn’t at all sure how to contribute an article, or even if I should/could

    1. Chris Mills wrote on :

      I remember talking to you about that issue Brian – thanks again for your thoughtful comments.

      If you do think of anything you would like to write about, or think we should cover, the best way to communicate it is to file a documentation bug (like you did before), or drop a mail to the dev-mdc mailing list (https://lists.mozilla.org/listinfo/dev-mdc)

  5. Martin Gray wrote on :

    I don’t have the slightest idea as to what this is all about. All I know is that my browser is slow and stalls and that I have to log off and start over several times a day.

    1. Chris Mills wrote on :

      Sounds like a problem that we could resolve. Have you reached out to Mozilla about your problems on any channels?

  6. Rajan Patel wrote on :

    My condolences about your transition to agile. Especially if it is anything like the workplaces where I have experienced it. Meetings about agile are the bane of my existence

    1. Chris Mills wrote on :

      😉

      We are gradually transitioning into an Agile process, trying to bring some of the positives around organization and progress, while also trying to stave off some of the negatives around it, like needless bureaucracy. These are just a couple of small examples, of course.

  7. Ondrej wrote on :

    If you find slack lacking in user permissions (and maybe features), try mattermost.org
    Voluntears and sprints do not really fit well together due to the tight time frame of a sprint as written above.
    So basically the question is what tasks could be done by voluntears and which by the core team?
    Or is there maybe a way to bring both together?

    Maybe you need an individual sprint for each volunteer with a bigger time frame (4 weeks)?
    You publish tasks that can be taken by volunteers. Volunteers can choose which *single* task they want to work on and finish in the personal sprint. Other volunteers can not take tasks that have already been taken until the assignees sprint ends. When the sprint ends, the task has to be reviewed, closed or if not finsihed it will be “freed” again, or taken into an internal sprint for completion. If not taken into an internal sprint the task is now “free” again and can be taken by some volunteer (eventually the same as in the last sprint) again. This way you would give volunteers time to decide on what to work on. They would have some kind of time frame which would maximize the time a task can not be taken over by someone else lowering the risk of tasks sinking into the assignees hands forever.

    Maybe being able to move/convert internal tasks to public tasks could help. As far as I know companies working in the open tend to have two task lists: one internal and a public one.

    1. Chris Mills wrote on :

      So basically you are presenting this idea of linked-but-separate streams for the work done by employees and volunteers, in terms of both exact tasks and schedules? I think this is really interesting, and we will definitely think about this. Cheers!

  8. Svetlana Tkachenko wrote on :

    Would suggest to make MDN translatable to other languages, as many as possible, and as easily as possible. And motivate people to actually do the translations. (On a related note, using the word “community” is elitist as it insinuates that there is a leading body which acts in its own interests and a “community” is only heard on the occasions when the leading body starts a “public consultation”. Where engaging people is truly wanted in long-term, in my opinion it is preferred to use words such as ‘we’, ‘people’, ‘society’, ‘everyone’, and so on.)

    1. Chris Mills wrote on :

      Thanks for the thoughts!

      We already have a translation facility on MDN, and quite a few languages have a strong translation community – take for example the recent milestone by the French community of getting all the HTML/CSS/JS references pages translated into fr.

      I am interested in your view of “community” as elitist — I think this is an interesting point, and it is always worth reevaluating your language to make it as inclusive as possible. In my view, “community” is very inclusive, as it gives people a change to get involved and contribute where they would not normally have that chance.

      I think you usually need to have some kind of central organization function inside the community, to keep things moving along, otherwise communities often descend into chaos. Where the elitism comes in, imo, is when this central organizer abuses their power, and/or doesn’t do a good enough job of ensuring openness and transparent comunication. This is often not premeditated, but it can happen if you are not careful, and we could certainly stand to improve on it.

      I’d be interested in hearing other people’s thoughts on this too.

  9. Spencer wrote on :

    First of all, Mozilla should be using Jira. There is no better task management system out there and Mozilla deserves only the best.

    What you’ve proposed here is just another example of why this company is a cut above the rest. There’s a real incentive to make the world a better place, and it is intoxicating.

    Anyway, I look forward to contributing to Mozilla products. Also, please hire me.

    1. Chris Mills wrote on :

      I agree Jira is nice system. It might be worth evaluating this as a more open alternative to what we currently use (Taiga).

      I’m glad you feel we are doing some good out there! Your words mean a lot to us 😉

      Wanna get hired? Have a look at the jobs pages https://careers.mozilla.org/listings/, and keep talking to us!

  10. MarkT wrote on :

    Hi Chris,
    Great to see this in discussion.
    I am keen to lobby for https://svgwg.org/svg2-draft/conform.html#processing-modes

    Where can vote for this to be in a sprint?

    Thanks!

    1. Chris Mills wrote on :

      Well, I am mainly coming to this from a documentation and marketing angle. For platform implementation, a good starting point would be to have a look and see if we have any bugs filed about implementing this feature (see https://bugzilla.mozilla.org), file one if not, and perhaps start a discussion on the dev-platform list (https://lists.mozilla.org/listinfo/dev-platform)?

  11. Orogun Lucky wrote on :

    It’s a good idea to maintain transparency even in a digitally divided world where election results and voting pattern could be manipulated on-line.
    Keep up the good job.

    1. Chris Mills wrote on :

      \o/

      I couldn’t agree more.

  12. David Bruchmann wrote on :

    I think a traditional forum is the best base to keep messages and make the searchable.
    Surly it could be combined with some AJAX, that makes real-time-chat possible in the threads and the possibility to mark posts as (not) relevant. Furthermore a summary for threads and involved persons would be a useful feature. Adding multimedia to a post should be no problem, perhaps also combined with a converter for uncommon file-formats, that the content at least can be seen by public even not used.

    These are only a few ideas, I’m sure if some more people think about it (or I’d think longer about it) there’ll come up still more feature ideas.
    Important will be an easy and intuitive design concerning the overview of all forums, the threads, posts and message-field in forums – especially if usage on smartphone is considered.

    1. Chris Mills wrote on :

      Thanks for the ideas David – keep em coming. We are looking to make the participation experience as painless as possible.

  13. ZCuteNuts wrote on :

    To have a Community to refer to and to pick their brains is vital, I’m convinced, yet it seems that we are not traversing the abyss of the need for the WWW/Internet to function freely.
    For me that means having a truly free CNU OpenSource ability to freely communicate via today’s growing preferred avenue – the Ethernet.
    At the end of 2016 the Linux Foundation conducted an online survey of the reliance on the Ethernet by CNU aligned businesses discovering that freedom of and free access to Ethernet is the uppermost resource for business development and yet it is an ever increasing business cost.
    As a home based buff that is the same for me.
    How about my fellows/fellowesses within the Mozilla Community, let alone those of the Linux Foundation Community, and what of those utilising other Unix Systems?
    How about a poser Chris on that in the form of a black paper (instead of a white paper).
    A freeby from me – sticking to such maxims as to the colour of paper driven by elitism bewilders me.
    How about presenting “a” Paper For Discussion?
    Please.
    ZCuteNutS.

  14. Nancy Carlson wrote on :

    Thank you for your work. In principle it is of the most important s. I wish there was something I could do to help however, I’m rather in the basement (so to speak) when it comes to what you need for lack of knowledge, but I do understand your work is of greatest needs. Keep up with all the good you are doing. Your work is in the frame work of freedom. God’s speed in Jesus name.
    Thank you again✝

    1. Chris Mills wrote on :

      Thanks Nancy, I appreciate the kind words.

  15. John Rieth wrote on :

    Hi Chris,

    I am very glad you wrote this post. I have some ideas that do not answer all of your points but I think answer a good amount. My ideas are also not completely fleshed out.

    The contribution page does not have any options to actually contribute code (https://www.mozilla.org/en-US/contribute/signup/). I think it would beneficial for there to be an option to see what Mozilla projects need assistance/help. I do not see how watching someone code or use Stumbler is getting involved Mozilla. It feels like Mozilla does not want actual contributors.

    Something similar to a UserVoice page could be an interesting way to allow people to contribute their ideas. I am sure Mozilla would get ideas that are not useful but I think a UserVoice page could be a low-cost way for people to feel part of the Mozilla community.

    The sites for Apache projects do a good job of relaying information about the project and how to contact project maintainers. Borrowing from Apache for keeping people up to date could be a good way to communicate.

    You wrote about how the agile process does not lend itself well to volunteer contributing. I wonder each project could have their own definition of agile. Some projects may be more agile than others. The less agile groups could be the starting point for volunteers.

    I do not know if these tools exists but there should be three levels of access to the tools. The first level is the level for people interested in learning about the project. Individuals in this level cannot comment and commit. The second level would be for volunteers. Volunteers have the ability to comment and commit publicly available code. The third level would be for core developers. This level would allow only those with access to discuss security issues.

    1. Chris Mills wrote on :

      Thanks John – you have made some really good points here.

      We are having a MDN meet up in Toronto later this month, and I am intending to run a session on moving forward and putting some of this into action. I will definitely bring these points up.

  16. Eduardo Aguirre wrote on :

    How can I contribute?

    1. Chris Mills wrote on :

      From MDN’s point of view, there is a guide here to getting started with contributing:

      https://developer.mozilla.org/en-US/docs/MDN/Getting_started

      It is still a bit heavy-reading though. One thing I do recommend is to join the #mdn channel on Mozilla IRC (https://wiki.mozilla.org/IRC) and/or join the dev-mdc mailing list (https://lists.mozilla.org/listinfo/dev-mdc), Say hello to us, and we’ll chat about what you can do.

      What we are hoping to do in the future is have mails sent out to the list to regularly say what we are working on right now, and to make it clear what items volunteers can help with.

      There are a lot of different tasks you could help with, depending on your skillset. The most common tasks I need help with are technical reviews, copy edits, and translations. You could also perhaps get stuck into helping us fix some documentation bugs, although that does require a bit more familiarity with MDN and how to use it.

      We can train you however, so it is not a huge problem 😉