One of the challenges that every community faces, particularly teams inside a larger community, is the ability to coordinate what goals and ambitions the team is going to work on. Traditionally this has always been somewhat ad-hoc: people join a team and work on whatever they feel like. Ideas are ten-a-penny though. For most teams that work on larger projects (such as events, software, products and more) to actually be productive, coordinating this work can be complex: some projects require coordination across many people with different skill-sets, time-availability and resources.
Something I have been socializing inside my own communities is a culture of best-practice in how we plan our work and coordinate our awesome teams to work together on projects. I believe this kind of coordination can help our teams increase the opportunity for success in their work, feel more empowered and productive and provide greater insight to people outside those teams on what the team is doing.
An effective way of doing this is to split up a project into a timeframe and build a Roadmap that captures a set of goals the team will work together to achieve in this period of time.
While at first a roadmap can feel a little like a nod to the gods of bureaucracy, they actually possess many benefits:
- Direction - one of the biggest complaints teams often report is a lack of direction. If a team gets into the habit of creating a roadmap at the beginning of a cycle, it gives the team a sense of focus and direction for the coming cycle.
- Documented commitments are more effective - a common rule in Project Management training is that actions assigned to people in a shared document are more effective than ad-hoc or private commitments. By documenting who will work on what in a cycle and putting their name next to an action can help seal a sense of accountability for their contributions to the project.
- Feeling of success - regularly revisiting a roadmap and checking off items that have been completed can develop a strong feeling of progress and success. It makes a team feel productive.
I spent some time recently in the Ubuntu community putting together a little bit of infrastructure to help making roadmaps as simple as possible. It may be useful for your own communities.
The first step is to open up a discussion with your team to talk about things that the team would like to do. As an example, a local user group may want to organize a booth at a given conference or work together on marketing materials, a documentation team may want to work together on a book or guide, a software team may want to work together towards a first release, and a translations team may want to work together on documentation to help translate a particular language and organize translations events and sprints.
The most effective of way of having this conversation is to produce a wiki page in which people can jot down their ideas and this can form the basis of converting key popular ideas in the team into roadmap items. Keep the discussion focused on the chunk of time that the roadmap applies to. You should make sure you have these discussions out in the open in your team communication channels, be it mailing lists, IRC channels or otherwise. It is important to note that not every contribution has to be on the roadmap. Roadmaps are great for larger projects and goals.
The roadmap is broken into a set of sections, each of which points to a particular goal you want to achieve. Each goal then has an Objective block which provides a task that needs to be completed to achieve part of the goal. Each goal can have *many objectives*.
The *Objective* block is structured like this:
- OBJECTIVE: An Objective is a goal that you want to achieve. Summarize your objective here in one sentence (e.g. 'Exhibit Ubuntu at OSCON' and 'Create Marketing Materials').
- SUCCESS CRITERIA: This is a statement that can be clearly read to determine success on the above Objective. This needs to be as clear as possible and not vague: it will indicate if you achieved the Objective (e.g. 'A successful exhibition at OSCON' and 'Website buttons, banner ads and wallpaper provided for local teams').
- ACTIONS: This is a set of steps that need to be executed to achieve the Objective. It is recommended that if someone volunteers to commit to delivering on an action, you put it in brackets (e.g. Print out local team logo on a banner (Jono Bacon)). There can be multiple actions for each Objective.
- DRIVER: If someone is coordinating this objective and helping those involved to deliver on their actions, list that person here (optional).
The aim here is to try and capture what your team wants to do and who will be contributing to the goal. Let's look at an example of organizing an event:
- OBJECTIVE: Exhibit Ubuntu at OSCON
- SUCCESS CRITERIA: A successful Ubuntu exhibition complete with demonstrations and materials.
DRIVER: Steve HarrisRoadmaps capture as many of these projects that make sense and apply the same structure that not only communicates what needs to be done, but also who has volunteered to work on which actions. When your community is invested in an open, transparent and structured approach to managing projects it can be hugely valuable in making the community feel nimble, able and accomplished at their work. Give it a shot, I am sure you will find it successful!
- Confirm booth space with OSCON organizers (Steve Harris)
- File a request for CDs from ShipIt (Bruce Dickinson)
- Develop artwork for main banner sign, staff badges, flyers (Janick Gers)
- Provide demonstration laptops (2 x laptops) (Dave Murray and Adrian Smith)
- Prepare demonstration speaking script (Nicko McBrain)
- Promote our presence on community forums, Planet Ubuntu and Full Circle Magazine (Steve Harris)