Bringing core tenants of Agile into open source development can result in a number of benefits [#Agile #AgileCore #OpenSource]

Bringing core tenants of Agile into open source development can result in a number of benefits [#Agile #AgileCore #OpenSource]

Establishing and understanding process
Providing stakeholders visibility
Measuring velocity and improving predictability

Agile and open source are really not at odds
Above all else, the Agile Manifesto emphasizes 4 key principles:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

It is these first 2 principles that often seem to clash with the way that most open-source projects are structured.

  1. While Agile programming heavily emphasizes co-location and the importance of face-to-face communication, open source is built on the very idea whereby anyone, anywhere, with any level of background can meaningfully make contributions to a project.

  2. Agile emphasizes working software over comprehensive documentation, but open source requires documentation in order to help provide history around the project and to help potential contributors understand where to get involved.

Despite the above differences, Agile programming does not have to be viewed as a juxtaposition to open-source development. In fact, bringing these core tenants of Agile into open source development can result in a number of benefits.

Establishing and understanding process
Given the distributed nature of open-source projects, maintaining order and focus is one of the most difficult jobs for open-source maintainers. For collaborators, knowing what to work on and understanding the guidelines for contributing to a project are similarly important.

In this way, creating a lightweight process around how work is prioritized and progress is tracked is critical to every stakeholder involved in the project.

Integrating a simple Agile framework like Scrum or Kanban into the project helps contributors better understand the process that work has to go through in order to be merged into the project. When paired with a set of contribution guidelines, a simple framework goes a long way to help build confidence among potential contributors to get involved and to know where to make the biggest impact.

Providing stakeholders visibility
Few things are more off-putting to potential collaborators looking to contribute to a project than not being able to understand if the project is still active and worth their time for a contributed effort.

Integrating Agile components into projects provides potential collaborators with a quick pulse regarding the activity of a project. First issues to contribute to, and which issues could be the highest priority for the project.

For example, Agile elements such as a lightweight task-board provide visibility into where a particular issue or pull request (PR) lives within the workflow of the maintainers.

Rather than submitting a PR and waiting for a comment or notification that the PR was merged, contributors follow along with their issue in real time on the board and understand how it is being prioritized against other merge requests that have been submitted to the project.

Measuring velocity and improving predictability
While it is true that the distributed nature of open-source projects prevents them from moving as fast as their commercial counterparts, it does not mean that open-source projects should not aim to continuously improve in velocity and become more predictable in their releases.

While it might not be realistic for certain open-source projects to organize work into sprints or iterations, there are other Agile metrics, that, when leveraged properly, can help projects measure and improve velocity and release predictability.

One such example of Agile metrics is Lead time and Cycle time.

These 2 metrics provide teams with the ability to measure how long it takes from when an issue or ticket is first created or first worked on to the time that it is completed.

Lead time and Cycle time can also help maintainers to identify outlying or stale issues.

If an issue has been open longer than the average lead or cycle time, this might signal that the issue is no longer relevant, or should be flagged as needing additional support from the community.

Adapted From
Agile and open source can complement each other:
SDTimes.com

Like this? Leave your thoughts below...

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Posted in:


Don`t copy text!