If you’ve familiar with object-oriented coding using any agile methods, you understand that the customer is at the center of the software development effort. The customers problems, her needs and goals, laid out in stories that the programmers return to every day: these keep the software from feature creep and UX failure. Delivering working software in small increments helps the customer reveal the moment they don’t need or understand something. The programmers can toss out that new feature and go back to the customer stories again with fresh insight.
They are testing all the code every day and releasing every week. So there’s never a time when the changing the software costs more than the last time. They are free to pivot toward some new capability that just might provoke delight in their customers; something they would never have tried if the cost of change was growing. Finally, they are solving their customers’ problems and building into the software new opportunities that might not have existed anywhere else in this way ever before. OK, so it rarely works out that well. But the philosophy of agile code development is sound and it offers valuable lessons beyond writing code.
Virtual organization community leaders would do well to consider how the Manifesto for Agile Software Development might be tweaked to be a working Manifesto for Agile Community Development:
Individuals and interactions over processes and tools
Working software (working volunteers) over comprehensive documentation
Customer collaboration (member collaboration) over contract negotiation
Responding to change over following a plan.
Let’s look at these one by one. Individuals and interactions are the daily work of the community leader. Staying in touch with members is more important than whatever tool (email, forum, listserve) is picked to accomplish this. Working volunteers build value and direction for the virtual organization. Having a grand, detailed volunteer guide is less important than having a team of members who want to move the organization ahead. Member collaboration means giving the membership as much ownership as possible. Staff are around to take care of day-to-day business, but budgets, planning, and the real work of the VO belong to the members. The staff are the sails, the members are the wind. Responding to change means having a full double-loop governance system and pivoting this to stay ahead of changes surrounding the organization. If you’re only following a plan, you are already lost.
Agile: it’s not just for software anymore!
photo credit: From flickr user magia3e http://www.flickr.com/photos/magia3e/6236962059/sizes/z/in/photostream/
One thought on “Who says that “agile” is just for software? Architect an agile online community!”
Thanks for sharing your thoughts. We are using agile concepts for work happiness and team building as well. If “team happiness” is the client, it wants us to do X …