User:RobertKaye/OnPlanning: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(Created page with "== On planning in a resource constrained non-profit == Recently someone paraphrased my stance on planning and how to decide what features to tackle as “Don’t worry about ...")
 
No edit summary
 
Line 10: Line 10:


# Not everything that makes it onto the roadmap or an issue tracker means that it has to happen. It is important to find the issues that many people care about (e.g. votes in Jira) and to work those into a plan for implementation.
# Not everything that makes it onto the roadmap or an issue tracker means that it has to happen. It is important to find the issues that many people care about (e.g. votes in Jira) and to work those into a plan for implementation.
# If an issue has been around for a long time, but no one has taken any steps for working on that issue, consider closing these issues, or to moving them out of sight. The goal is to remove the task from the list of things that must constantly be considered.
# If an issue has been around for a long time, but no one has taken any steps for working on that issue, consider closing these issues, or to moving them out of sight. The goal is to remove the task from the list of things that must constantly be considered. This can be a tough thing to get right -- we should use our best judgement to make decisions, but we should move forward.
# A roadmap must remain flexible: Even the best plans are mere guesses for what might happen in the future. New opportunities arise. Newer ideas/knowledge may make future plans obsolete. Given a constant stream of changes, a roadmap must cope with change.
# A roadmap must remain flexible: Even the best plans are mere guesses for what might happen in the future. New opportunities arise. Newer ideas/knowledge may make future plans obsolete. Given a constant stream of changes, a roadmap must cope with change.
# A roadmap must be maintained: The second a roadmap is published, it is out of date and it will only get worse over time. Unless someone is dedicated to maintaining the roadmap, having a hopelessly out of date roadmap is worse than not having one.
# A roadmap must be maintained: The second a roadmap is published, it is out of date and it will only get worse over time. Unless someone is dedicated to maintaining the roadmap, having a hopelessly out of date roadmap is worse than not having one.
# Finally, a roadmap should not hold the team working to implement hostage. Because a task was added to a planning document is in no way a commitment by the team that this will absolutely get done. Lack of resources and changing circumstances can make what seemed like a good idea at the time, a bad idea in the current context.
# Finally, a roadmap should not hold the team working to implement it hostage. Because a task was added to a planning document is in no way a commitment by the team that this will absolutely get done. Lack of resources and changing circumstances can make what seemed like a good idea at the time, a bad idea in the current context.





Latest revision as of 12:59, 10 June 2015

On planning in a resource constrained non-profit

Recently someone paraphrased my stance on planning and how to decide what features to tackle as “Don’t worry about it, planning is not important”. This is very much not the case -- let me explain my thinking on this.

Successful open source projects have a lot of people participating in the projects. And along with the “Many eyes make all bugs shallow” philosophy, comes “many people have many ideas”. It is easy to have an idea (a little harder to have a good idea) about something that a given project should do. It is also fairly easy to open a ticket for this idea in hopes of getting this idea implemented.

But, there often times there is a disconnect between the number of ideas generated and the number of people working to realize those ideas. Implementing ideas is much harder and much more time consuming that coming up with ideas. This leads to the inevitable backlog of ideas and open tickets that can have a negative impact on the team working on these tickets. “We’ll never get this done!”, “Gah, so much work, I feel overwhelmed!” are common and valid responses.

This makes planning something like a roadmap quite challenging. If all you can see is a mountain of tickets that overwhelm you, it can be hard to plan. When planning for the future there are a few things to keep in mind:

  1. Not everything that makes it onto the roadmap or an issue tracker means that it has to happen. It is important to find the issues that many people care about (e.g. votes in Jira) and to work those into a plan for implementation.
  2. If an issue has been around for a long time, but no one has taken any steps for working on that issue, consider closing these issues, or to moving them out of sight. The goal is to remove the task from the list of things that must constantly be considered. This can be a tough thing to get right -- we should use our best judgement to make decisions, but we should move forward.
  3. A roadmap must remain flexible: Even the best plans are mere guesses for what might happen in the future. New opportunities arise. Newer ideas/knowledge may make future plans obsolete. Given a constant stream of changes, a roadmap must cope with change.
  4. A roadmap must be maintained: The second a roadmap is published, it is out of date and it will only get worse over time. Unless someone is dedicated to maintaining the roadmap, having a hopelessly out of date roadmap is worse than not having one.
  5. Finally, a roadmap should not hold the team working to implement it hostage. Because a task was added to a planning document is in no way a commitment by the team that this will absolutely get done. Lack of resources and changing circumstances can make what seemed like a good idea at the time, a bad idea in the current context.