7

We all know that Scrum works very well for a traditional team where team members come into work each week/sprint, agree goals and meet commitments.

However open source projects are often very different:

  • People tend not to work on Open Source projects full time
  • While some projects have a group of core contributors many pull requests are ad-hoc with people submitting pull requests which most likely won't contribute to any agreed sprint goal
  • Communities are often run via messaging systems, blogs, and forums rather than formal meetings like plannings sessions, retrospectives, and sprint reviews
  • The direction of projects is often more of a democracy (or whoever contributes the most) rather than being focused by a Product Owner

Do these differences mean the scrum methodology cannot be applied to an open source project or do adjustments need to be made?

Improve this question
5
  • 4
    What do think is more important: to shoehorn an open-source process into a corset like Scrum? Or to have a working process, containing all the important elements from the SDLC (like requirements gathering, analysis, design, coding in small cycles, configuration management, tests, quality assurance, release management, maintenance), even if the name "Scrum" does not fit?
    – Doc Brown
    Commented Feb 9, 2018 at 9:55
  • @DocBrown clearly a working process, in fact your comment asks pretty much what I'm hoping to answer - namely whether the framework as we know is would be a good fit or whether scrum it would feel shoehorned (and if so what elements do and don't work)
    – Liath
    Commented Feb 9, 2018 at 10:37
  • 3
    @Liath, you'd have to analyse what development processes are for. For example, one of the benefits is to allow bosses to monitor progress and provide a delivery schedule, glean accumulated experience about how long things take, take remedial action along the way (by allocating extra resources or adjusting other plans), and to disclose (and therefore discourage) high-risk, open-ended projects with unquantified schedules. For an open-source project, which may be embarked upon precisely for its novelty and uncertainty, and have no formal deadline, how beneficial are these metrics?
    – Steve
    Commented Feb 9, 2018 at 10:58
  • ...the only sensible use of such processes in a small volunteer team of open-source developers, would be if they were trying to create a context in which they could learn and rehearse the behavioural aspects of the processes themselves (which may or may not include any insight into what those behaviours are actually for or how they fit into a larger organisational structure, and the rehearsal may not include the full complement of roles that would exist in a firm operating on a commercial basis). Rather like cops and robbers, with only robbers.
    – Steve
    Commented Feb 9, 2018 at 11:07
  • If those involved can make scrum work why not? It just may attract the kinds of developers you want on your open source project.
    – JeffO
    Commented Feb 9, 2018 at 12:48

3 Answers 3

Reset to default
7

Open source projects are very diverse. There are some where a Scrum-like approach can work, but not in the general case.

Scrum timeboxes work into fixed-sized sprints. There are many open source projects with a fixed release schedule. But usually, this schedule is about integrating work that has already been done, not about doing the development.

Scrum expects the team to commit to a sprint goal. But most open source projects are driven by volunteers. Contribution is voluntary and fluctuating. It would be toxic for these projects to feel entitled to a repeated dependable commitment from volunteers. The project cannot tell volunteers what to do. It can of course refuse to accept contributions that are not part of the sprint backlog, but that's an idiotic waste of goodwill and development resources. Speaking as an open source maintainers, one-off pull requests with a bugfix are tremendously valuable. But this contribution is in no way planable.

There are of course scenarios where this would not be a problem. E.g some development may be paid for through grants. These grants may specify a goal and/or timebox. But grants are typically given to a single person, not a team. Sometimes projects are led by paid contributors, e.g. for a project that was started by a company. The company can of course use Scrum to plan their contributions.

Improve this answer
3

I assume by open source project you do not refer to projects that are worked on by paid employees. "By the book" Scrum usually won't work, because there's some difficulties:

  • Sprints require firm time commitments, and benefit a lot from regular and repeated firm time commitments.
  • Scrum benefits from frequent team interaction, which is easier if most of the team is in the same office or at least in a similar time zone.
  • Based on my experience, Product Owners - on average - tend to be significantly better if they are not actively writing code for the project.
  • Quite a few contributors have a specific interest in specific features they want to develop, few to no interest in some other features, and no incentive to listen to anyone who wants to tell them which features to work on.
  • Different time commitments create difficulties in arranging a daily stand up meeting

The issues can be worked around, and with the right project and the right people Scrum may work anyway. But even then, there are probably better processes.

I recommend you break down Scrum and take the stuff you need, then implement in a way that fits the project and the team:

  • Have a clear project vision that is known and accepted by all.
  • Have a shared prioritized list of things that should be done sooner than others.
  • Make sure people know who's currently working on what.
  • Have regular short to medium term shared goals, and reviews after they have been reached.
Improve this answer
2

Saying Scrum can't work because of those arguments is like saying that Scrum can't work in a company, because they are currently using waterfall. While Scrum and waterfall don't play well with each other (or rather contradict each other) it does not mean that you cannot establish Scrum there, if everyone goes along. Likewise I would not state that Scrum can't work in an open source project per se, but it comes with its own straits.

People tend not to work on Open Source projects full time

While this is true, Scrum embraces this kind of uncertainties, too. Given we have a very short cycle of one week, everyone that wants to contribute will have to commit for at least that one week and plan how much time they will be able to spend on the project. Based on how much time every contributor can afford, it's possible to plan the stories to work on. Anyway, doing Scrum won't be really possible, if the contributors tend to stay away from the mandatory meetings.

Of course this is not restricted to weekly sprint cycles.

While some projects have a group of core contributors many pull requests are ad-hoc with people submitting pull requests which most likely won't contribute to any agreed sprint goal

Open source does not necessarily mean that everyone can contribute like they want to. There are open source projects with very strict rules on how to contribute (Linux for example). People planning to contribute to the project will be required to attend the sprint planning, etc. You can make this a requirement to contribute to the project. Of course people disliking this may create a fork and work on this how they like, but this will be another project, then.

Communities are often run via messaging systems, blogs, and forums rather than formal meetings like plannings sessions, retrospectives, and sprint reviews

You can have the formal meetings via telephone- or rather videoconferences. While this does not make Scrum easier, it's well possible. Just because it is not done in the projects it does not mean that it can't be done.

The direction of projects is often more of a democracy (or whoever contributes the most) rather than being focused by a Product Owner

Yes, you will have to have someone who acts as a product owner. Again, the usual practice does not keep you from doing it differently. Furthermore, there are examples of single persons driving a project an steering it in one direction (again, think Linux).

Long story short, while you are probably correct that it's anything but the rule, I don't think it is impossible. If you have a competent owner chosing and prioritizing the user stories and contributors that are willing to contribute that way, nothing will keep you from doing Scrum.

EDIT

Anyway - as was pointed out by the commentors - it's quite likely to be a mess and probably not a good idea. Just to mention some points why it might fail:

  • It'll be hard to get a hard core of contributors - without it, Scrum won't play its strengths
    • Without a very stable team you could roll a dice to estimate story points - it might work equally well
  • with the Scrum overhead it will be even harder to recruit enough contributors
  • Commitment levels will most likely not be high enough

(Side note: A Kanban-like approach might work better if you'd like to give some structure to your OSS project. It does not depend on roles, the buy-in is way lower and it's much more time-flexible, but still gives you a good overview of the WiP.)

Improve this answer
8
  • Brilliant answer, exactly what I was hoping to see
    – Liath
    Commented Feb 9, 2018 at 10:10
  • 3
    It does seem to presuppose a high degree of organisation and commitment on the part of the volunteers - and all parties here seem to have accepted that that cannot be taken for granted. I assume the number of people who are willing to entirely accept the strictures of commercial employment, but without pay, are relatively few in number. And once you have relatively few people involved (including no bosses and no customers), formal processes carry overheads without much return - in fact, it may only serve to reduce the number of available volunteers.
    – Steve
    Commented Feb 9, 2018 at 10:49
  • 4
    This answers has a very major flaw - it assumes a unrealistic level of planning from the general open-source community. I'm not saying that people that plan their time for the Open-source projects in a extremelly dedicated manner, but really - I won't miss the unplanned burguer night with my fellows just because a random open source needs a new network driver or some correction on its scheduling engine. Scrum works with high commitment - something that you can't expect at all from any open-source contributor. It isn't their job.
    – T. Sar
    Commented Feb 9, 2018 at 11:22
  • 3
    @Liath It may be what you were hoping to see but it isn't something that will work well on practice. Even for leisure stuff, like WoW guilds, this kind of organization is hard to achieve. A lot of people contribute to open-source projects because it is relatively easy - scrum will just be a roadblock that will remove people from the process, not help them.
    – T. Sar
    Commented Feb 9, 2018 at 11:24
  • 1
    @DocBrown Thank you for your honest, but still constructive feedback.
    – Paul Kertscher
    Commented Feb 9, 2018 at 12:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.