I see this question popping up quite often in different conversations. Recently, we had a good discussion about it within my team. The main question was about how to communicate openly with the community, as well as have the space to build a team and work as a team. This can be challenging; for example, when a company or a sponsor pays a part of the contributors to work full time on a project.
In this article, I will explain why agile works with the open source development model.
Building agility with transparency
My idea of agile is that it is a mindset rather than a set of processes and tools. As the quote says, "Don't do agile, be agile." So what are the core values of this mindset?
An answer to that question is The Heart of Agile. This initiative aims to make agile simpler and more human. It emphasizes the four following values:
- Collaborate
- Deliver
- Reflect
- Improve
Image credit: heartofagile.com
These are compatible with open source values—open source is all about collaboration and delivering the result of that. Reflection and improvement help us adapt to changes and provide the opportunity for an honest look in the mirror.
Now, what about transparency? Scrum is often presented with three pillars—transparency, inspection, and adaptation, though these are not limited to Scrum and can be applied to agile as a whole.
Can we apply these pillars to open source as well? Absolutely, and I would even go so far as to say that it is one of the best examples of those values in action.
Open source development provides a direct link between the developers and the users of a software. Discussions happen in the open, and everyone is welcome to give their opinions. This results in the users feeling valued, which leads them to be more involved in the project.
The core values of both agile and open source overlap, so why do we still think that agile does not work for open source?
Building the community is creating value
In agile, we talk a lot about creating value, the main idea being to simplify processes and focus on delivery. A possible downside of this is that it can lead teams to focus only on delivering new features and not invest enough time to pay back technical debt or build on automation to facilitate the future growth of the project. A way to avoid such a situation is to involve the team in defining what creating value actually means for the project.
Image credit: Perry Grones via Unsplash
How does that relate to open source? For any team working in an open source community, it is crucial to understand that building and caring for that community creates value. In open source, the community is the heartbeat of a project—it provides crucial feedback, support, and documentation and contributes in many other ways.
So, whatever process is used by a team, it is important to build in time and space for the community. Invite people to review your user stories; after all, you do have users in your community. Dedicate time to reviewing contributions, answering questions, providing support, etc. All these should be part of the team's activities and be seen as valuable.
"Default to open" does not mean 100% open
Building a team also requires building trust between its members. To allow this trust to grow, the team needs a safe space to have conversations. In most cases, for this space to be safe, it cannot be open to the wider community. Such a space allows the team to grow, discuss possible improvement, and enforce good internal practices. It can also be used to provide constructive feedback if needed.
An important warning, however—be careful not to overuse that safe space. If all conversations default to that safe space, then the team loses transparency. The team should remind itself to default to open communication channels, and only use the safe space when needed. Embracing the "default to open" motto lets the team challenge itself when to use, or not use, that safe space.
As such, when it is appropriate and consented to by the team, you should consider sharing the output of these conversations with the wider community. That will uphold the practice of transparency while ensuring ongoing trust between the team and the community.
What do you think about agile and open source working together? Share your experiences and thoughts on the subject in the comments!
Comments are closed.