Best Practices for Project Management
The monthly cycles presentation introduces the new way of working within Linaro's teams setting a process and targets to service better our partners and improve our cadence in producing quality deliverables. Some of the challenges in introducing the monthly cadence have been
- Improving the way work is documented in blueprints and work items using Launchpad
- Improving the deliveries for the monthly milestones, including proper highlights, and indicating overall what blueprints are implemented with each milestone
- Identifying exceptions and deciding how to handle those: for example, non-binary work items (including but not limited to documentation, discussion with 3rd parties or community, or experimenting prototypes which are not usually part of an official tested release)
Some of the vocabulary and best practices in transitioning to the monthly cycle have been:
- Based on the technical requirements agreed on for cycle 11.11, Engineering blueprints are created. Each of these blueprints contains a whiteboard where the work items are listed indicating the basic work units to implement the target of the blueprint. Engineering blueprints constitute the cycle backlog.
- Engineering blueprints are associated with a project. There are two types of projects we use: normal "component" projects (related to a SW component, eg library, binary, image etc) or workgroup projects. The latter are projects which can represent work which does not necessarily release a particular component or binary.
- Each project can have a series of releases and milestones on that series marking the time when significant events take place: eg the release of a particular version of the code
- For the monthly planning we do the following: Right after a monthly release, the assignees will choose the work items for next monthly release and target them to the next monthly release milestone in the whiteboard of the blueprints. Currently, this is being done during the Tech. Leads and the assignees 1x1 meetings (eg for the Toolchain WG, this is done on Monday following the monthly release). If all Work Items in the blueprint will be done in the next monthly release, the whole blueprint will be targeted for the next monthly release milestone.
Example blueprint with work items planned for the monthly workgroup milestones: https://blueprints.launchpad.net/linaro-multimedia-wg/+spec/engr-multimedia-forum-summit
Note that if the work for a monthly milestone is associated with the binary release of a particular SW component then a milestone is created for that project (in the format YYYY.mm) and bugs, blueprints composing the work to do for that release are associated with that milestone.
It can happen that if a group has all their backlog in Workgrpoup project blueprints, then any planned work items which will result in such a SW component release are split from the original blueprint and put in a new blueprint which is targeted for a monthly milestone of the corresponding SW component project.
Example blueprint with work items planned for a component release: https://blueprints.launchpad.net/glcompbench/+spec/engr-benchmarking-glcompbench-2011.07,
Example of a component project milestone: https://launchpad.net/glcompbench/+milestone/2011.06
For the powerdebug project, a new blueprint is created for the next monthly release milestone (let us call it a Milestone blueprint) and a dependency is created from the Engineering blueprint on this new Milestone blueprint. The Work items that will be done in the next monthly release are moved from the Engineering Blueprint to the Milestone blueprint. The Milestone blueprint is targeted to the next monthly release milestone.
internal/archive/pmo/ProjectManagement/BestPractices (last modified 2013-08-27 00:11:38)