Look into Kanban. It’s more appropriate than SCRUM for your constraints.

Edit: SCRUM is (very roughly) an ordered backlog with sprints and ceremonies to ensure that the volume of work ‘in progress’ stays under control and have something solid at the end of every sprint. If you ditch the ceremonies and the sprints cadence you end up with Kanban: an ordered backlog and a strong emphasis on limiting work ‘in progress’ directly and by making sure everything marked ‘done’ is done rather than by imposing stability at the end of each sprint.

You still get the agile benefits: release anytime, flexibility, some measure of predictability – although SCRUM can get you slightly further on that aspect – and without the ceremonies or aspects of SCRUM that don’t fit well a loose, distributed team with no commitment. The catch? Ditching the ceremonies require more discipline, so you REALLY need to pay attention to tests, code quality, the current work in progress, and ensure the top of the backlog (stuff ready to be picked up by people) is sufficiently elaborated.

You could have a vote based backlog, although in a volunteer setting some people just work on whatever they want to.

(And yes, all the TDD, CI, reviews and peer programming ideas are good ideas).

To address the differences you note first:

• That your members are volunteers does not mean you can’t ask them for a commitment. Especially with the relatively short duration of a sprint in Scrum, it must be possible for each of the members to know how much time they can commit to the project for the next few weeks. Having the team members available for a different amount of time each sprint will make the planning a bit harder, because it is harder to determine how many storypoints are realistic, but it does not make Scrum infeasible.
• The product owner is responsible for consolidating and communicating the vision (and requirements) that the stakeholders have for the product to the development team. The consolidating part is probably already covered by the ‘steering’ committee. For the communication part, they can just delegate one of their members as their primary spokesperson. That one will then for all practical purposes be the product owner.
• Not having an external deadline is not really a problem for Scrum. It just comes down more on the pride of the team in the product to get it finished. Scrum itself has a natural deadline for each sprint.

Regarding your proposed adaptations, especially when working with volunteers, I would strongly recommend to keep to the fixed sprint length. That way, the volunteers know definitely for which period they are giving off their commitment.

I also wouldn’t ditch burndown charts immediately. They can also be useful for the team itself to see how they are doing on their commitment. I would leave it up to the team to decide to keep or ditch them. The same goes for the velocity calculations. especially with the large variation in available manhours each sprint, they can prove very useful (especially if you calculate the number of points completed per manhour) in estimating future sprints.

Regarding daily standups, they will still be useful in your setting, if only to let it be known what everyone is up to or has problems with (and that is independent of complexity). But it might be harder to realize a daily standup, so you might need to compromise there.

The XP practices you mention can be introduced or not independently of the use of Scrum and could also be proposed during a retrospective.

It surprises me that no one pointed it out, but your project seems like most open-source projects. If you check out some more popular open-source projects, you might find some inspiration. And I think you should forget about SCRUM and think about this from perspective of general agile.

Agile is a all about communication and collaboration. There is reason why there 2 points out of 4 in Agile Manifesto talk about it.

Individuals and interactions over processes and tools

Customer collaboration over contract negotiation

And the way you describe your project, it would be difficult to have face-to-face communication with everyone working on the project, something both Agile and SCRUM encourage. So first thing I would focus on is to establish communication channels for whole team (both volunteers and product committee). Things like wiki, forums, videoconferences and proper backlog, task and bug tracking system are great ways to ensure everyone knows what is happening and what needs to be done.

Second thing I would note is not to just brush around the technological parts of agile. Many believe (myself included) that they are the ones that make agile work, not the process side of things. Code review is important and most open-source work by having someone who knows the project review the commits/push to ensure high enough quality is maintained. TDD is practically given for any agile project. It ensures any changes to the code don’t break the previous functionality which is even more important in your case when volunteers cannot be bothered to fix other people’s errors and mistakes. It also makes code review easier because reviewer can see in tests what functionality was added and by running them he ensures the functionality actually works as intended. Continuous integration is same as TDD. It ensures the application does what is intended by allowing short feedback loop with customer/product committee.

Last thing is that I believe you should have at least few people working on the project full-time. Those people should have specific roles:

• Product owner : While it is nice you have a whole committee dedicated to this, there should be one person who is responsible for interpreting this committee’s words into specification or user stories and ensuring they are properly implemented.
• Coordinator & Scrum Master : This person should be responsible for the whole process and ensuring that everyone knows about the important things happening in the project. Also, he maintains the wiki and task&bug tracking tools. If someone has a question about the project, this is first person they should ask.
• Main developer & architect : The person who knows the code best. He does the code reviews and ensures the quality of code is good enough for agile development.

You cannot adapt it the way you are describing and still call it SCRUM. but in my opinion, you can use Scrum like following for the setup you have described.

1. Have fixed iteration. So that you can measure your progress. This is
   not for just for management but also for team to “know” how they are
   performing.
2. Ask volunteers to share capacities at start of iteration. All team
   needs to what members are committing otherwise certain member may
   leave the team for work that more professionally done.
3. Having no deadline is fine. Scrum doesn’t forces that however what
   you do at the end of each iteration should be potentially shippable.
   This will let you decide what to do next based on what you have done
   till then (which is working).
4. Having no product owner is can work as well.. You can have some sort of voting
   system to stack rank backlog and accept/reject work done.
5. Requirement gathering is not part of Scrum. You can do it anyway you
   want it. But do not include that as part of iteration scope. Have
   separate capacity for that. So for a iteration, plan only that work for
   which requirements are clear e.g. team knows the acceptance criteria.
6. Retrospective are good. So start Scrum as it but then using
   retrospective see what is working and what is not e.g. you may need
   to change iteration size, you may need to get rid of some volunteers
   who are dragging everyone else..
7. Daily status are must. That gives opportunity to team to sync with
   each other i.e. they will align their efforts so that no task gets
   unnecessarily blocked due to unavailability of other member’s
   deliverable.
8. XP is good. Have a strict definition of done based on XP e.g. no
   code goes in unless reviewed. Do less to do more..

I might suggest a different approach. Since you’re dealing with volunteers you have a few things to consider. Your team will probably have a high turnover, life will get in the way and people will get distracted. Of those left a few will contribute consistently but not very much, then lastly you’ll have that hardcore group who really sink their teeth into the project. I’m making a lot of assumptions about your work force here and if you feel that my assessment doesn’t reflect the people you’re working with feel free to ignore the rest of this.

Now you need a strategy that will allow people who don’t do a lot of work to be able to work fairly autonomously, they only have so much time to dedicate to this and you don’t want to make them spending the majority of that in communication. The people who are more involved should be responsible for integration and flushing out some of the more complex ideas.

This leads me to think of a development process more focused around wire frames and prototypes.

You can have a pool of work items available and encourage people to write wire frames for those. You can use these as Tracer Bullets (terminology borrowed from Pragmatic programmer) to hone in on the idea and provide inspiration for people to build on. From there you can graduate the successful ideas into prototypes, again these are very small projects designed to help the people learn more about the projects. After that you now have a smaller section of solid ideas that have been built by a multitude of people that you can hand off to some of the team that is a little more active and they can work to integrate those ideas into your system.

I think Kanban would fit better for this situation.

Scrum has a few things that do not fit. The timing or scope measurements are not necessary and everoyone developing has the same product vision from the meetings. Accountability and following a short plan with consistency are business objectives.

Kanban offers quite a lot of the same advantages as Scrum without its disadvantages. It can give you rapid prototyping. The protypes can be run prior to meetings. It also gives TDD for changeable code and regression tests. Pair programming can ease newcomers and non regulars in to the code base by transferring knowledge.

Kanban also has unique advantages. If the vision of what the users do is being developed in parallel, Kanban works well. Proof of that is success for small business programs. Also, for the days with few volunters such as three people, Kanban would still work well. Scrum, despite being lightweight would be too much yellow tape.