8 Lessons in Being Agile from the Open-Source Community

The open-source community can teach us a few things about being agile whether you follow Scrum, Kanban or any other agile approach.

1. Open-source teams tend to be decentralized with a minimal hierarchy. This enables fast decision-making. Multiple levels of approval aren’t needed to get things done.

This level of autonomy can be difficult to accept but the productivity gains make it worthwhile. Let your teams define their own structure and reward system. Define clear guidelines and success parameters then let them go.

2. Open-source teams value intellectual contributions. The people that make the most valued contributions are the ones with the most influence and control. No one just goes along for the ride.

This approach follows the agile principle that results matter more than anything else. People who complain and criticize carry no weight with the team unless they can offer a better idea and help others implement it. Forget rank and job title. Only results matter.

3. Open-source teams collaborate. They use forums, email, instant messaging, and other tools to stay in contact and share information. They don’t write lengthy documents as a means of sharing information.

Resist the corporate call to generate extensive paperwork. Offer the minimal level of documentation that corporate watchdogs require. If they want more, offer them software artifacts instead such as source code, use cases, architecture drawings, etc. Avoid creating new documents just for outside review.

4. Transparency matters to open-source developers. Source code and documentation are readily available for anyone to review. Ideas aren’t hidden or protected. They’re shared.

Provide access to all project documents including source code to any employee that wants it. Don’t hold back. Withholding any information will only invite closer scrutiny and criticism.

5. Open-source teams actively involve end users throughout the development cycle. Early and frequent feedback provides a self-correcting mechanism for the team. Many small corrections are easier to manage and integrate than a few major ones near the end of the project.

Work directly with the user community. Don’t rely on marketing or some other group to act as a liaison. First hand feedback is always the best.

6. Peer review is one of the stalwarts of open-source development. Team members look forward to having their work reviewed by their peers. This is one of the key ways that they learn from each other and develop their skills.

Peer review must be an assessment by other developers not professional reviewers who no longer write software. The team must respect the reviewer for this to work.

7. The open-source focus is on continuous improvement by incremental, not monumental, change. Small, frequent changes allow for rapid development and feedback cycles. Both quality and productivity improve.

Keep project timelines short. If many new features are being demanded, group them into a series of short projects or iterations. Insist on user feedback after each iteration.

8. Time is not rigidly controlled on open-source projects. Quality and stability are valued more than getting the next major release done by a predefined date.

This works because there are multiple mini-releases of the software along the way. The major defects are corrected and many people install the application before the final release is delivered.

Energize your teams by challenging them to produce results not documents. Give your teams the tools they need to be successful. And most importantly, get out of their way and let them succeed.

Updated: September 19, 2011 — 10:34 pm