Do good, better. CoActivate is a platform for social activism.

  • The 12 Disciplines

last modified September 23, 2010 by strypey

Paper for FreeCulture2010

The 12 Disciplines

"You got to learn to connect, and bring change" - Shapeshifter, 'Bring Change'

"Do the simplest thing that could possibly work", says Patton [1], and it's a curious coincidence that the Agile Manifesto development principles [2], Holmgren's permaculture design principles [3], and Rob Hopkins' ingredients of Transition [4], all break down to 12 key points. It would be no surprise to find correspondence between the Transition and permaculture principles. After all, Transition began as a community-driven response to peak oil and climate change by activists and permaculture teachers like Rob Hopkins [5]. What if we compare either Transition or permaculture with Agile? The agile and permaculture principles potentially link up in a few different ways, but I have laid out what I think are the strongest correspondences (see Appendix A). I did the same with the Transition ingredients and the agile principles (see Appendix B). In both cases, I was excited by how easy it was to line them up. Then, fearing a confirmation bias, I wondered, "am I the first person to see these correlations?". Apparently not.

A blog post by "edible landscape" designer Ethan Roland generalises the Agile principles, "pulling the most-useful for ecological and social landscape design to the top" [6]. Roland makes some of the same connections I did, matching principles on 'change', and 'self-regulation and feedback', but he sees some of the parallels differently. For example, whereas I paired Holmgren's "produce no waste" with the Agile 'simplicity' principle of "maximizing the amount of work not done",  Roland linked it with "LEVERAGE your work to do the greatest good for the greatest number of beings for the longest amount of time", a principle from his own 'Directives for Architects' [7]. While I put Agile's "working software is the primary measure of progress" together with Holmgren's "catch and store energy", Roland saw it as "obtain a yield", a principle I matched with Agile's "satisfy the customer". My suspicion is that a programmer would think of the working software the same way a permaculturist thinks of a designed ecosystem, as a means to an end, and in a commercial software project the end is user satisfaction.

Another set of comparisons was made by Robert Dober, a contributor to a Ruby forum on FLOSSPlanet [8]. He highlights the reference to sustainability of development, "The sponsors, developers, and users should be able to maintain a constant pace indefinitely", as being akin to permaculture. This goes against the grain of the biological principle that has more recently become part of permaculture thinking, that ecosystems, like organisms, have a 'pulse', and the pace of emergence is never constant. However, it does point out the need for the development process to sustain the energies of all of its participants in the longer term, and watch out for collective habits that are self-exhausting, as do the other two Agile principles he mentions about iteration ("slow and small solutions" in my correlations), and "reflects, tunes and adjusts" ("feedback and self-regulation" in my table).

Since the internet is one big global pond, it makes sense that the ripples from two pebbles like  permaculture and Agile being dropped into it would eventually touch, overlap, and start to create interference patterns. So what about Agile and Transition? Being 'in transition' is often discussion in Agile writings, such as Patrick Wilson-Welsh's article on adoption of Agile development practices [9], and the different transition strategies been used in different companies. Similarly references to agility are scattered through Transition writings, but it seems these two sets of ripples have yet to consciously overlap.

Even so, Wilson-Welsh's article could easily be generalised in a way that would apply to the iterative progress made by a Transition initiatives, and the strategies that have been tried in different communities. For example, transition is a journey not a destination; get endorsement from management (local government); start with a team who are in regular in-person contact; let team members stick with their pet projects; identify way the community lacks resilience, and deal with those first; decide on methods for measuring the success of a project before you start organising it; simplify systems at every opportunity; ask your community whether they are ready to transition together, or whether to start with a small proof-of-concept project. His  conclusion sounds exactly like Transition at work, an example: "Work to assuage fears, to celebrate positive results. Be patient if things get sticky. When all else fails, return to ways to create even more community. Do anything else you can to bring people closer. Celebrate every small success with food."

So are these correspondences mere coincidence? The result of the same creative interpretation that sees dragons in clouds, and faces in tree trunks? Or is there a unifying pattern lurking beneath all these examples? One answer is that permaculture, Transition, and Agile, are all applications of systems thinking; to human habitat design, community planning, and software development, respectively. Both Meadows [10], and Kevin Kelly [11] offer us a sets of emergent principles they claim can apply to any dynamic system, but arguably, it's possible to identify common principles between any two things if you abstract them enough.

Bodies of theory are all very well, but to be of any use, they have to be applied. The strengths of all these adaptive design practices become clearer when they focus the wisdom of crowds [12]; and organise 'barn-raisings' - community mutual aid exercises - to solve problems under the most chaotic and stressful of circumstances.