How can Scrum be adapted to a Volunteer setting?

Question

I have recently joined a young hackerspace still in the process of setting itself up. We're fortunate because the space has a few internal projects that need working on and no shortage of volunteers to work on them.

There have been some discussions on how to organize these projects. My most recent professional experience has been with Scrum so I'm considering pitching a Scrum approach for our software projects, but I'm not sure it will be a good fit.

Although I've seen Scrum work well for small full-time teams, the nature of this organisation is different:

• The members are volunteers. Some are full time students. Others work jobs full time. We can't expect a constant level of contribution from anyone as their real lives take priority.
• While pretty much everyone has years of experience writing software, not many members have done so professionally or in teams.
• There is no Product Owner. The requirements for these projects are determined by a committee. The members of this committee will also be working on the implementation. This means we will have no single, dedicated, Product Owner.
• We have no deadlines (soft or hard). The projects will get done when they get done.

These are pretty significant differences, but I'm not convinced they will be blockers to applying Scrum. I think some minor tweaking could get us over this hurdle:

• If we change Sprints to have a fixed story-point size, but fluid duration (time), we can still benefit from iterative releases without putting unrealistic delivery pressure on volunteer devs.
• We can ditch burndown charts and velocity calculation. If I understand correctly, these are tools and metrics that work as a bridge between the dev team and the Management. They serve to report progress in a form that is meaningful to both the developers and the stakeholders. Considering we have no one to report to (no Project Manager, no Product Owner, and no outside stakeholders) I believe we can drop this altogether.

Things I think we could benefit from which won't require tweaking:

• The Requirements Gathering meeting(s). Where everyone sits around a table and discusses User Stories, sketches up UI mocks, and builds up a Product Backlog.
• Sprint Retrospectives. This will be an interesting way for us to converge on a development process that works for us as a team of volunteers.

Things I'm not sure about:

• How should daily Stand-ups be treated? I wonder if they would have much value at all in our setting. My understanding of the stand-up ritual is that it helps communication by naturally disseminating information throughout the team. Considering the fact that our Sprints will likely be delivering much less complexity than an average Sprint there might be less need to be abreast of all the other team members' progress/developments.
• Should I push for XP things like Continuous Integration, Code Reviews, and TDD? I'm concerned this will be asking for a lot. I'd be more tempted to bring these concepts in on future projects once people are more familiar with Scrum and working as a team.

My Questions:

Can Scrum be adapted to a volunteer-based environment?
And, is my planned approach so far going in the right direction?

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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..

Answer 5

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.

Answer 6

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.