Applying Agile Methodologies to Open Source Volunteer projects?

Question

What Agile principals can be extended to classical volunteer Open Source Project Management?

Challenges compared to a traditional workspace.

1. Managing burnout / over-commitment of volunteers.

2. Enforcing accountability, without shaming or otherwise making organization members (or outside contributors) feeling isolated or abandoned.

3. Getting accurate estimates for releases, how to deal with deadlines without a consistent base workforce.

4. Handling the public / users who are demanding, because being 'whiny' often gets them the attention they need, at the risk of long-term dev burnout.

5. Keeping interest in your project / community by developers (rather then users)

I think you would be able to do scoping, and estimation pretty easily, you could track velocity, which could help point out signs to burnout early, as opposed to meeting a future release (keeping the 'when it's done it's done' attitude).

Answer 1

Open source projects inherently embody one of the Agile Manifesto's main principles: The best architectures, requirements, and designs emerge from self-organizing teams.

Making sure you create an environment for motivated individuals that supports their needs and empowers trust to get the job done is easier said than done, but essential for creating valuable software that satisfies customers. This is the highest priority of any Agile undertaking.

More often than not, accountability is an artifact of transparency. If team members have the courage and openness to be transparent about what's going well/not-so-well, accountability and teamwork naturally occur.

Burnout can be mitigated by releasing valuable, working software on a regular, sustainable basis. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace.

More often than not, developers want to work on interesting projects that show progress. Working software is the primary measure of progress, thus should be a focus.

My source for this feedback is the Agile Manifesto principle page, which can be found here

I recommend using these principles as a benchmark for your purposes. Good luck!

Answer 2

I would recommend looking into the Kanban Method. This method focuses on the flow of work rather than the more common agile "iterative and incremental" approach. Kanban starts with just a few basic ideas, all of which would be applicable to open source volunteer projects:

1. Make the work visible as tasks on common visual board with at least the following categories: Options (also sometimes called Backlog), Committed, In Progress and Done. In this case, using an electronic tool such as Trello or LeanKit. Each piece of work becomes a virtual "card" on a virtual "board". All volunteers would need to access this board. Making the work visible allows volunteers to self-organize around the work to do. In other words, if I am a volunteer, I can look at the board and choose a task that has not been started, select it and start working on it without needing to coordinate with anyone else. If I want to work on a task that is already started by someone else, I can find out who that is and contact them to coordinate.
2. Limit Work-In-Progress (WIP) by setting simple policies about how people volunteer for work. This is where Kanban differs from Scrum in some important ways. Basically, on the "board" the Committed and In Progress categories of work get limits on how many tasks can be in-flight in those categories. For example, if you observe that the board has 25 items in the In Progress category, you might ask the community to agree to a maximum of 20 items (always lower than the current amount). If the community agrees, then a policy is set in place that work can only be brought into In Progress if there are 19 or fewer items currently In Progress. This changes your work to a pull system.
3. Establish a regular cadence for community discussion on how to improve the work system. With a volunteer group, this will often be every several weeks or few months. This is roughly equivalent to Scrum's Sprint Retrospective meeting. The participants look at the work and decide if there are any experiments that can be run to help make things more efficient, effective, higher quality, more productive, etc. Typically, this will include simple ideas such as breaking the In Progress category into different stages such as Design, Develop, Validate, changing WIP limits, or deciding on how to document tasks more effectively. It might also include more sophisticated things such as community policies around asking for help, collaboration, choosing tasks, types of tasks based on risk profiles, etc.

There are many more aspects to the Kanban Method that would help. I recommend reading the ebook Essential Kanban Condensed and consider taking a Kanban Method training class from the Lean Kanban University (note, some of my colleagues teach these courses in the Toronto area).

The biggest challenge with a volunteer open source initiative and other agile methods such as Scrum is that the methods tend to enforce some rules that would be difficult or in appropriate for such a community. As a simple example, Scrum requires daily meetings with the whole team to do status reports. With a volunteer community with many people spread around the world, this is extremely difficult to do properly - and not worth it! I'm a Certified Scrum Trainer and I would never recommend using Scrum for a volunteer open source project. If you are interested in reading about Scrum, I recommend the Scrum Guide as it is the official definition maintained by the creators of Scrum, Ken Schwaber and Jeff Sutherland.

One other advantage to applying Kanban in your situation is that it is possible to introduce it gradually and in a very gentle manner. Most other agile methods tend to require disruptive changes to the way that a group works together and so can incite resistance.