Tag Archives: working open

The scrum never stops: building an open workbench for Webmaker

As we head into Q2, let’s build a better “workbench” and online scrum board for Webmaker.

TLDR version:

  • Check out the freshly udpated Webmaker Wiki. It’s one-stop shopping for key roadmaps, planning documents, tickets, and scrums. And will help provide more transparency and co-ordination across teams going forward.
  • It clearly lays out Webmaker’s key components. And how they all fit together. From teaching kits and training to localization, badges, and Maker Party. These will provide the main tracks for our scrum board as we go forward.
  • Shifting to real time production, instead of static documentation. The new wiki is a production document. The main goal is to provide a clear view of *what we’re building now.* Week by week, quarter by quarter. Instead of a static repository for documentation that quickly goes out of date.
  • Project scrum boards. To that end, each individual project page will lead with a virtual scrum board at the top of the page. We’ll embed Bugzilla tickets to do this, and use Bugzilla components and whiteboard tags to do it in a smart, automated way. (If you don’t use Bugzilla, just include links to wherever you’re tracking the work.) Continue reading The scrum never stops: building an open workbench for Webmaker

Working open: 7 recommendations from Mozillians

Last weekend’s Mozilla Summit was inspiring. Here are 7 key recommendations that came out of the “Practicing Open” session David Humphrey and I facilitated in Toronto.

The goal: gather specific suggestions around how to work in the open at Mozilla.

How do we commit to open not just in terms of technology, but in terms of how we work? How do we embrace  transparency, encourage innovation without permission, design for participation and agility, and empower community?

Where is that difficult? Where do we need to adapt or improve?


 1) Reaffirm open as our default way to work

Working in the open was a defining part of Mozilla’s history and culture. But do we still believe in it the same way? Is it still practical?

Working in the open carries risks. The press closely follows everything Mozilla does. Sometimes individuals’ blog posts are mis-reported as official Mozilla policy. Sometimes early prototypes get treated as product releases. And we have grown exponentially, straining our traditional culture and systems.

Working open can be messy and difficult — but the message coming from Mitchell and others at the Summit was: it’s still essential to our continued success.

Here’s Mitchell in conversation before our “Practicing Open” session at the Summit:

The hidden costs of becoming a conventional organization — and following the best practices of other organizations — are huge. And maybe a silent killer. We can’t just adopt what everybody else does, where no one can say anything publicly. When we do that, we go slow, we lose agility, and we lose the personality that attracts people to Mozilla.

Jlin fully embracing the spirit of the weekend. (cc @kathrynmeisner @Mozilla) #mozsummit

2) Work in our pyjamas, jeans and dress clothes

Working open is not an either/or, or an all-or-nothing. Mozilla is both an open source project and a brand that carries weight and needs protecting. The Mozillians we talked with are very aware of these dual priorities, and hungry to dig into this issue with greater nuance, complexity and specific detail.

Mitchell offered a metaphor that could help us frame this: the “working in your pyjamas vs. bluejeans vs. dress clothes” metaphor.

When we’re not always polished, we’re taking a risk. But if we’re always in our ‘dress clothes,’ we risk our authenticity. We risk going slow. We risk losing what makes us special.” –Mitchell

There are times when Mozilla needs to present a polished, authoritative face to the world. But there are also times when we need to be more casual, and there are times when we need to be wide open, unguarded and permissionless.

You wouldn’t show up for a job interview in your pyjamas. But that doesn’t mean you spend your whole life in a business suit, either. Sometimes you hang out at home in your pjs. Sometimes you put on a pair of jeans and a t-shirt to walk to the store. And sometimes you dress up in formal businesswear.

As Mozillians, we operate in versions of these three styles every day. When we disagree about where the lines are, it’s helpful to acknowledge the need for all three spaces — and then try to get the nuance right for each. Rather than trying to straitjacket ourselves into working like a traditional organization.

Moz Summit Sunday

3) Share updated guidelines and best practices

To put that metaphor into practice, we need more specific team-by-team guidelines.

Many of the Mozillians we talked to would like clearer social guidelines around when and how to work in the open — particularly in relation to public relations and media. Its often unclear what those protocols and best practices are. And when things go wrong, it can result in frustration or anger from colleagues.

“When you don’t know where the lines are, it costs you agility.” —Coop

Common questions and scenarios included…

  • “I’ve collected a bunch of data from my research. When can I share it on my blog?”
  • “I released an early prototype that’s blowing up on Hacker News! What should I do?”
  • “I posted something publicly that upset some colleagues. They told me not to do it again. Now I’m unsure of what the rules are.”

These issues are complex, and a natural challenge for an organization as open as Mozilla. But “hand-slapping” or getting mad at people after the fact is not a strategy — it just leaves people feeling confused about what the best practices really are. And it can create a chilling effect that costs us agility.

We've got you, Firefox. #mozsummit

4) Reinvest in mentorship

“A big part of working open at Mozilla means mentoring and being mentored.” –David Humphrey

Mozillians highlighted mentoring and being mentored as one of the most effective means to put working open into practice. Newcomers (whether staff or volunteers) need meaningful guidance around open culture, social rules, and the human element that makes Mozilla special. Documentation and wikis are no replacement for this human touch.

Sometimes we talk about this in terms of an “on-boarding process” or better manuals and documentation. But a big part of the challenge is seeing how its done. And the best way to do that is to have someone show you.

Informal mentorship has always been one of Mozilla’s strengths. But our rapid growth (how do you provide mentorship to 200 new Firefox OS hires?) and accelerated release cycles have put a strain on the informal mentorship practises that used to happen more often.

The hurdle is learning the social rules…. All organizations have this — but you can’t just follow standard corporate rules at Mozilla. You are participating in a much different community.” –Maris, MDN

Open Badges session with post-its

5) Work out specific guidelines for how we share data

Mozillians often gather various kinds of data in their daily work. How do we collect, report and share that data in the right way?

We’re not really talking about personal user data here, which of course stays under lock and key. But what about things like performance data, privacy experiments, Bugzilla contribution data, etc? This issue seems like a recurring sensitivity and was a frequently asked question.

Crazy for the Open Web

6) Seize the risks of working open to tell our story

Occasionally things deviate from the plan. How do we respond when working in the open triggers unintended consequences or unexpected attention?

Every time we react to a problem, we train the media. We teach them how to look at Mozilla. We can either train them to look at us as a traditional ‘software company’ — or help them see us as an open source community.” –David Eaves

Our reaction to these instances can guide how others understand and report on Mozilla. When we act like a traditional software company, it may train others to treat us like a software company.

But when we lean into the fact that Mozilla is an open source project, with a broad and diverse community, it could reaffirm the ways in which we’re different. And challenge ourselves to really tell that story. It’s harder to do — but probably worth it in the long run.

7) Work like the web we want

Open doesn’t just mean open in terms of using Bugzilla or GitHub. It’s a frame of mind for both practical market success and long-term mission success. –Mitchell

At the Summit we talked about building the web the world needs: one that’s knowable, interoperable and “ours” — a web that belongs to people, and that people are able to shape and make their own.

Those seem like great principles for building the Mozilla we want, as well: a Mozilla that is more knowable (transparent, friendly, and well-documented), interoperable (collaborating across teams, locales and projects), and ours (built by and for community).

Other organizations belong to owners and shareholders. As a non-profit with a mission, Mozilla belongs to people. To make that meaningful, it’s probably not enough to just serve the public — we have to let them in. That starts at the atomic level, with how we work each week.

Next up: Gather more specific case studies, examples and your feedback. What do you think? How can others help?

How to work open at Mozilla

Mozilla Festival

What does “working in the open” mean? How do we do it at Mozilla — and where do we need to adapt, adjust and improve?

Those are some of the questions we want to explore in the Mozilla Summit’sPracticing Open” session. The goal: start with a lively discussion around the key issues and themes — including some new ideas Mitchell has been sharing around open. Then work together on something more lasting and concrete: a new FAQ guide on “How to work open at Mozilla.

Creating an FAQ together

We’re definitely not going to come up with all the answers on this complex topic in two short hours together. But we can brainstorm some great questions and common issues, then follow up on answers together after the summit.

Of course, many smart Mozillians have already done a lot of thinking, writing and sharing around this topic in the past.  We’ve been trying to gather some of those links and resources here — please add your own favorite resources and readings under line 115. (Huge thanks to David Boswell for all his help here.)

But an FAQ specifically on working open at Mozilla doesn’t already exist, and it could help put some of our existing resources into helpful context — plus identify gaps we need to update as we move forward.

Get involved

Gov 2.0 guide to Plone

Why does working open matter to Mozilla?

Part of what makes Mozilla special is a unique *way of working.* Mozilla is committed to open not only at the level of technology, but also in terms of how we work — for decision-making, discussion, working on specific tasks and bugs, communications and community. It’s a defining part of our culture and history.

That culture and way of working faces new challenges and opportunities. Mozilla has grown enormously in size. The scope and complexity of our products has increased. Specific product requirements can sometimes clash with the goal of transparency. Some documentation and systems may now be out of date.

How should Mozilla practice open in this new landscape? Where are we succeeding? Where are we failing? Do we need a new understanding of when, how and why to practice open? How do we strike the ideal mix of pragmatism and idealism that define “working open” at its best? And how do we make all that practical — answering questions you may have in your everyday work?

Let’s surface those questions together.