Every quarter the apps team gets together to meet people and talk about all
the pieces of the projects. This quarter we’re doing a little different format
which I think will turn out to be a lot more social and hopefully keep things
interesting. As part of the project I put together this short video talking
about Q2 for the Marketplace. Thanks to all the developers working on the
Marketplace, Andy McKay for the payments videos, and Katt Taylor for helping
piece it together.
Ten years ago, Ben Smedberg
and Wolf landed the first version of
the code that would make up AMO.
At the end of 2004 it was still called update.mozilla.org, written in
PHP, and was just over 200k, compressed.
One of our stress points is juggling too many projects. It's easy to hear ideas pitched from excited people and agree that we should do them, but it's hard to balance that with all the other commitments we've already made. At some point we have too many "top priority" projects and people are scrambling to keep up with just the bare minimum - forgoing any hope of actually getting the enhancements done.
With a large number of projects, developers begin working independently to finish them which increases feelings of isolation, contributes to poor communication ("I don't want to interrupt you"), and delays code review until someone can context switch over to look at it. Basically we've hit a point where - on large enough projects - working separately is slowing down our delivery and lowering our team morale.
In addition to being spread too thinly, there is also the question of why are we working on the projects we're working on. In theory, it's because they support our company goals, but that can often get muddled in the heat of the moment and interpretations and definitions (and even memory) can affect what we actually work on.
The work week helped highlight these two concerns and after several discussions (thanks to everyone who participated) we came up with some solutions. I'll address them in reverse order - firstly, to determine priorities (the why), we wanted a more objective and public way of ranking the importance of projects. A public list of projects not only lines up with our open philosophy, but helps developers and the community know who is working on what, and also helps anyone requesting features get a feeling for a delivery timeline. Our solution was to build a grid with 16 relevant fields which we rank from 0-5 and then sum to get a final score. The fields are categorized and are broken down as follows:
Who finds value from the request? Separate points for consumers, developers, operators, OEMs, and Mozilla employees.
How does the request align with the company goals? Separate points for each goal.
How does the request align with the 2014 Marketplace goals? Separate points for the three goals.
Lastly, is there internal necessity? Separate points for Technological Advancement, Legal Compliance, and Urgency.
Once we have a request, a champion for the request meets with representatives from the product, UX, and developer teams, as well as any other relevant folks. We discuss the request and the value in the specific areas and then add up the score to get a number representative of priority. Clearly this isn't a hard and fast science, but it's a lot more objective than a gut feeling. It lets us justify decisions with reasoning, helps us think of all affected groups, and makes sure we're working on what is important. If something has a high score we'll start talking about timelines and moving things around, keeping in mind commitments we've made, planning and research that needs done, and any synchronizing we need to do with other dependent teams.
The other issue - people trying to do too much - is easily solved in a conversation but will likely be a challenge in practice. The plan is to cap our active tasks to 3 or 4 at any one time. Anything else will queue up behind them or displace them as appropriate. The exact number may change based on size of the team and size of the project, but my goal is to get 2 to 4 people working on a project together and with our current numbers that's about what we can do.
I'm working on a real-time public view of our tasks but I'm traveling this week and haven't had a chance to finish it. I'll post again with a link once it is finished.
Update Feb 13: Added links to goals.
Years ago someone asked me what the fastest way to stand up an App
Marketplace was. After considering that we already had several Add-on Types in
AMO I replied that it would be to create another Add-on Type for apps, use the
AMO infrastructure as a foundation for logins/reviews/etc. and do whatever minor
visual tweaks were needed. This was a pretty quick solution but the plan evolved
and “minor visual tweaks” turned into “major visual changes” and soon a
completely different interface. Fast forward a few years and we have two
separate sites (addons.mozilla.org and marketplace.firefox.com) running out of
the same code repository but with different code. Much of the code is crudely
separated (apps/ vs mkt/), but there are also many shared files, libraries, and
utilities, both front and backend. The two sites run on the same servers but
employ separate settings files.