In this series of posts, I’m discussing a bit about what I’ve learned regarding open source project management, specifically through the context of the WordPress Plugin Boilerplate.
The thing is, a number of these lessons are relatively commonplace in any team-oriented environment; however, when you’re working in the open source culture with an unofficial distributed team, there are nuances to the work that aren’t always as easy to manage as they are when it comes to running projects in a face-to-face environment.
In the last article, I talked a little bit about vision and mission as they relate to running projects for yourself, for a distributed team, or even potentially for a organization of some type.
This article is going to focus on something that’s all too familiar with respect to software development: milestones.
But just as others have written about content in the past (and will continue to write about it in the future), I think it’s something worth sharing today – at least with respect to my own experience – in open source project management.
Open Source Project Management: Milestones
For the most part, I think anyone involved in software development – be it web applications, desktop applications, embedded applications, and so on – is familiar with the word milestone just as much, if not more, than they are with things like sprints, deliverables, and so on.
But the type of milestone I’m talking about works hand-in-hand with maintaining the vision and mission of the project, as well as how to more easily organize what’s nice-to-have, what are must-haves, and perhaps even how the nice-to-haves will be must-haves in a future iteration of the project.
As it relates to software, I think the best definition of a milestone is provided by Wikipedia:
A milestone is an event that receives special attention. It is often put at the end of a stage to mark the completion of a work package or phase. Milestones can be put before the end of a phase so that corrective actions can be taken, if problems arise, and the deliverable can be completed on time.
But perhaps it can be defined more simply: A milestone is a collection of features and bug fixes that work their way into the next deliverable of a project.
And the reason that I think it’s important to define this is because a milestone usually results in at least one of several things:
- A tagged version of the project that’s ready for the next release
- A phase of the project in which previously known bugs have been addressed
- A phase of the project in which new featured have been introduced
- A phase of the project in which certain features have been deprecated or removed (for any number of factors)
The reason that it’s important to maintain milestones is so that everyone who is involved working on the project is not only aware of what needs to be accomplished for the next iteration, but how they can also help to maintain the vision and mission of the project not only at the global level, but at the current working level.
What Goes into a Milestone?
Perhaps the most difficult part of managing a project like this is determining when a feature should be implement (or if it should be implemented at all).
First, some features are easy to determine. That is to say that you can see how they are bug fixes for known issues, or are pre-requisites for other features that will come later.
Secondly, they are direct improvement to the architecture and/or or organization of the project such that implementing the change in the next iteration will improve development (however this may come at the expense of breaking prior releases).
Finally, sometimes features and issues are simply delayed because of time. That is, they are delayed until the next release or until a future state (or an indeterminate date) until there is time to implement the actual work.
Must-Haves, Nice-To-Have, and Converts
In software, it’s all too common and popular to talk about the features that are must-have and that are nice-to-have, and the hard truth is that some of the people who aim to stick to the things that are must-have end up throwing the kitchen sink at the application ultimately resulting in a less-than-lean-1.0, and that results in bloat.
It’s kind of ironic, but that’s a whole other post.
Anyway, the point that I’m trying to make is that the must-have features can be easily identified by those that are absolutely critical to ship to the product in such a way that it provides the end user with the features they need to successfully solve the problem at hand.
That is, without this given feature – or set of features – then something is clearly lacking. And this goes back to the vision of the project (which, recall, is a clear mental picture of what could be, fueled by the conviction that it should be).
So look at it this way: if you’re working on a feature, you may be able to determine what a must-have by asking yourself if this contributes to the project as being “what is could be, and what it should be.”
On the other hand, the nice-to-haves are viewed as luxuries. For example, if there’s a feature that you want to implement, but it doesn’t contribute to the core vision or mission of the project, then it’s something that’s not necessarily worth integrating right now.
Or perhaps maybe ever.
And as for the converts? These are the things that were once nice-to-haves that turn into must-haves.
The conditions under which this happens varies greatly – it can depend on the demand for the project, the environment in which said product is being development, the competition around the product, or simply new features of the platform on which the product is developed.
But as I’ve said many times before on this blog, I’m a big advocate for having a “strong 1.0,” but to take it a step further, I try to be a strong advocate for having as lean an iteration as possible as it relates to the current release.
“This Doesn’t Tell Me How To Sort The Issues.”
I know – and sometimes it’s hard to know; other times, intuition will step in and guide you.
But in the times that it’s difficult to tell, you just have to draw the proverbial line in the sand and say that “this milestone will be complete when this set of issues is completed.”
And that’s that.
Worst case scenario, you’re moving stuff into the next milestone giving your project a roadmap, extending it’s life, and giving your work a chance to get out in the wild sooner rather than having it stuck in development hell.
And there’s something to be said for that.
But that feeds into the next post in the series – specifically, that enters into the territory of issues. And I’ll be covering that next.