One thing I have been working hard to continue to grow and refine with each cycle is how I manage my team at Canonical, the projects that we are working on, and how we coordinate ours and other projects with the wider community. As I have focused on improving this project management approach, I have been working to help better structure and plan our projects.
While I started doing this with my team specifically, I was keen to see if I could improve this in the wider community too. As such, at the last Ubuntu Developer Summit I worked to better socialize the idea of teams developing a firm idea of what they want to achieve in a cycle, planning that work out, assigning the work across the wider team and making steady progress on those goals throughout the cycle.
To do this I encouraged teams to build roadmaps with a core set of goals, divide those goals into blueprints and to track actions inside those blueprints. Some teams embraced this more structured approach and were successful in achieving their goals.
As part of this work I approved a set of blueprints that I would manage as part of my team. This core set of blueprints, a mix of my team’s and other community goals, set the primary goals and workflow for my team throughout the cycle, and my role was to keep everything on track.
At the start of the Ubuntu 10.04 Lucid Lynx cycle I blogged about these plans for my team in Lucid. They included these blueprints:
Engage in outreach with targeted upstreams to build support for Application Indicators into their code
Help communicate needs of upstreams to Launchpad team
Continued documentation for Upstreams
Get Harvest more production ready
Improve Kernel community patch flow
Facilitate transition of Permissions Reorganisation
Help the IRC Council in being effective
Improve translation status reporting
Increase community participation in coordinating translations
Definition of translations best practices and policies
Improve Quality Assurance on translations
Increase community developer contributions in Launchpad Translations
Raise awareness of LoCo team work
Help the LoCo council to be successful
Make LoCo Directory usable for the LoCo Community
Release Party Coordination
Ubuntu Free Culture Showcase
Improve UDS Scheduling
Team Sprint Planning
LoCo Docs Day(s)
Release Name Announcement
https://blueprints.edge.launchpad.net/loco-directory/+spec/community-lucid-loco-directory-development and https://blueprints.edge.launchpad.net/loco-directory/+spec/loco-directory-event-registration
So, we had a large set of blueprints with an even larger set of actions and I was keen to ensure I could provide as much support guidance across these different communities and blueprints.
I did by using the burndown chart approach that we in the Ubuntu platform management team have been experimenting with recently. I decided to trial this for the Lucid cycle to see if it would help me provide a sense of perspective and oversight over the team, and more importantly, help optimize my team and the community for success.
As we draw the Lucid cycle to a close, the burndown looks like this:
For those unfamiliar with a burndown chart, the Y axis is the number of committed actions in all of the projects I am managing, and the X axis is the time until the end of the cycle. Each bar on the chart indicates the number of items yet to do (red), the number of completed actions (green), and the number of postponed actions (orange). To use the chart effectively I need to keep the number of completed actions under the thick black line; this then provides a constant stream of progress across the collection of actions.
Doing this effectively is not as simple as saying “make sure you complete two actions every day until the end of the cycle”. Some actions take seconds to achieve, some actions take days to achieve. As such, while using the chart, I found myself developing a better awareness of the size and scope of tasks so I could better plan for the team. This was particularly important around vacations, holiday periods and other downtime.
I already have a pretty structured way of managing the team; we have weekly calls, I sent out call notes, create new actions, review outstanding actions etc, and the burndown just factored into our weekly workflow in a fairly non-invasive way.
While the burndown is primarily a useful tool for me, when I look at that chart I am hugely proud at how the team was responsive to keep the various projects on track. While this certainly applies to horsemen Castro, Holbach, and Planella, this also applies to the wider community. Take a look at the assignment summaries:
Let me explain what we have here. Across all of the blueprints that we committed to with their included actions, this is a list of who had actions assigned that affect the burndown. Naturally Jorge, Daniel, David and I have the largest assignments, but I am hugely proud to see that (a) we had lots of community participation and (b) those who did participate were hugely successful in completing their actions. Even there many folks only had a few actions to complete, this experiment demonstrated to me that the tool is useful for helping raise the opportunity for success.
As such, in the Maverick cycle I am going to use the same approach, but continue to encourage more community participation in these structured blueprints. I think that the burndown approach not only helps me guide all these projects and keep them on track with a regular flow of achievements, but it also helps raise my visibility on the different actions which helps me easily identify the next pieces of low-hanging fruit and coordinate with the community around completion of those tasks and unblocking any problems.
So, in a nutshell, I am proud of everyone’s achievements and I look forward to even more success in the Maverick cycle