About Agile for Volunteers

Stepping Back

It has become fashionable in 2023 and 2024, and for years before in fact, to attack Agile as ineffective, a waste of time, and worse. This is arguably due in large part to the way Agile has been implemented in workplaces that rely on coaches and some rigid structure, productivity and scoring of that productivity, and grading the contributions of members of a development team, using charts and tables of numbers to make decisions. In these scenarios, there is often a sense that Agile is being used as a tool for control and judgement rather than a methodology and set of principles that enables and encourages accomplishment, collaboration, and inclusion of the Whole Team in a development effort. The Whole Team includes not only developers (in a software project context), but management and customers, so that a project is less surprising as it evolves to tackle specific discoveries about initial design direction while still advancing the overall development direction toward established directives.

In other words, a system designed by software developers for software developers, to bridge some of the gaps that persist today all to often, has been degraded into something it was not intended for. This is debatable, and could be the subject of much discussion, but if someone tells you that Agile does not work, the first question one might ask is if the Agile Manifesto entered into the methodology at all in their experience.

A Work in Progress

The Agile for Volunteers Initiative will always be two things:

• A work in progress subject to discussion, iteration, and with some luck, improvement in the way we collaborate to make the most of and correctly value the time, effort, and experience contributed to Initiatives and Projects to further their movement toward milestones (development, deployment, improvement, and so on)
• A starting point for any Volunteer Cohort—including one-person cohorts—to make opportunities to contribute to Volunteer-driven, Community Elevation Initiatives and Projects a matter of discovering them, with a working set of principles and methods that will focus the time, effort, and expertise on the tasks at hand, not on trying to find documentation, project plans, and so on.

Application to Non-Software Initiatives

The original Agile Manifesto was created by Software Developers for Software Developers. The Whole Team approach does make the business side of any project a part of the team, the Whole Team is not a sequestered team of programmers isolated in cubicles or working from home. Another of the Principles we quite here:

Business people and developers must work together daily throughout the project.

There is an implication here, with Agile for Volunteers we make it Explicit. The Whole Team includes all contributors, as coders, artists, editors, translators, testers, project managers, and anyone else making an initiative move forward, including the customers and users and consumers of these efforts who can take part early on as part of an iterative Co-Creation Process. The Initiatives and Projects themselves need not be Software, and in fact might not be more often than they are. Some might prefer working with User Interface and User Experience, some with language translations to make sure we are communicating with as many as we can, some might work with accessibility so that not only language, but specific user interface and user experience make our projects useful and usable by those who might need them, or want them, without presumptions about vision, hearing, and so on. A single initiative may have many elements that are not software at all, but every Volunteer contributor is a part of the Whole Team to accomplish the goals of the Initiative and its Component Projects.

First Principles

The Manifesto for Agile Software Development was published in February 2001, the result of software developers coming together to discuss some ideas, inspiration by Extreme Programming principles and methods, and ways to gather some of the existing and new ideas into a coherent plan for Software Developers at large to implement. Arguably, as a starting point. The Agile Manifesto is translated on the website into many languages, and for good reason.

The brief Principles behind the Agile Manifesto page on the site, which has been translated as part of their homepage translation links (please visit there for their own translations to many languages), lists many useful principles which may be applied to a Whole Team Agile Approach to software development (or, as we will suggest, many types of development efforts beyond software). includes as its final princple, this:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

It is this final principle (perhaps one of several) which is often forgotten in the Agile Industrial Complex implementations of Agile, often foisted upon development teams without this essential principle, where the Whole Team reflects on what is working and what is not working, reflecting on where to make changes to be for effective, to work together in more productive and satisfying ways, and in the case of Volunteers, to make the best use of the time, effort, and expertise Volunteers bring to any Initiative or Project, and to the Whole Team itself.

We added a few things at the end there, but the fundamentals of Agile for Software Developers are only more viable as principles for Volunteer Collaborators working on Community Elevation Initiatives, where working together to make the most of these limited Volunteer resources (time, effort, expertise) is something the Whole Team should be thinking about, and here we have a perfectly functional starting point grounded in real experiences of real professionals.