launchpadblog

In my last post, I explained how squads doing maintenance picked the next bug to work on. But how does it work for the other squads?

We have two squad that works on a project which is usually a feature. In this context, a feature means something that will take a team of 4-5 engineers several weeks (or months) to develop. It will usually need a good amount of discussion with the stakeholders to clarify requirements  and we’ll do user testing along the way.

We maintain a short queue of 2 projects to work on next. The items on the queue are determined through the Stakeholders Meeting process. The stakeholders cabal meets once a month (when there is a free slot on the queue) to discuss what’s should be the next items to be developed by Launchpad feature squads. The way it works is that before the meeting interested parties send in their proposal with justifications as why this is the most important piece. People discuss each other proposals. Then the Launchpad Product Strategist (Jonathan Lange) and I will come back with a proposal taking into account the stakeholders discussion. That proposal is discussed during the meeting and a decision on what to add to the Next queue is taken. We try to operate by consensus, but in the end, the Product Strategist has the final say.

The stakeholders group composition which is made of one representative from the major teams within Canonical derives from  the business goal of Launchpad which is to give Canonical a competitive advantage in delivering a high quality OS.

An error that is easily made from that would be to think that only the interests of people within Canonical matter in determining What’s Next? If that would be the case, it would be a very shallow view on our part and we would miss the more general aspect of achieving our business goal which is also to accelerate open-source software development. (Still to give Ubuntu a competitive advantage over proprietary solutions, but hey, it’s a well-known fact that Canonical is a for-profit company.)

The burden of taking into accounts the wide-majority of non-Canonical Launchpad users fall on our Product Strategist’s shoulders. He listens closely to users, in person, on mailing lists, by taking into consideration things reported during user testing sessions. You can always find his long-term plans on the roadmap.

I want something in, who should I talk to?

• If you are within Canonical, talk to the representative working in your unit.
• Otherwise, talk to the product strategist. The easiest way is to start a discussion on the launchpad-users mailing list.
• For Ubuntu folk, we area working with the Ubuntu Technical Board to get a representative who would cater for Ubuntu Project as a whole. But they still haven’t made a decision as to whom they will appoint. Once they are appointed, you should contact them. In the mean-time, talk to the strategist.

Not all features are created equal

Not all feature requests will take several weeks for a squad to implement. For those that can be tackled by one engineer in one or two weeks, they’ll be taken by one of the maintenance squad. These small features can escalated by the stakeholders. (That was the other mechanism by which a bug could be escalated to Critical in my last post.)

When we put items on the Next queue, the feature definition is quite vague. It will specified through a LEP by the product team and the assigned squad once it’s time to work on it. But how that work and what happens after that is probably the topic for another post (as is the answer as to why people write LEPs before we decide to work on the thing).

Hope these posts shed some light on how we decide What’s Next?

Photo by Anonymous. Licence: CC BY 2.0.

This entry was posted by Francis J. Lacoste on Wednesday, May 4th, 2011 at 10:02 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.