Anarchy with a Purpose—a Model for Emergent Awesomeness
An amazing crowd of volunteers organised the first gathering of the Agile Lean Europe network, ALE2011. It happened last week, and being part of the organisation team has not only been an honour and a pleasure, but also the most successful project I was ever involved with. Why? Because the organisation was emergent, the leadership and responsibility distributed, the team passionate and hard-working, and the outcome and created value outstanding, evaluated by the people who attended the unconference.
As I talked with various people before, at and after the event about our organisational model, my understanding of how and why it worked so well grew, so that now I can start summarising and explaining what we did. This will be a multi-post endeavour, which I hope to finish within a week, and I’ll do it in a way that you can give feedback and improve my thoughts along the way. The main step is done: Eelco Rustenburg already found a working title: Anarchy with a Purpose.
This first post will only give you the most important influences and a first insight into how we collaborated, decided, and measured progress. I’ll structure it in a way that each topic can (and will) be elaborated upon in a subsequent post.
The Purpose—Start With WHY
[amazon asin=”1591842808″ template=”simpleimage”] The gathering had a simple and very compelling purpose: our joint vision to grow a network of sharing practitioners. People volunteered because of this purpose, speakers and participants came and paid and shared because of that purpose, and it was a clear goal to follow while we designed, planned and created the event. WHAT we did and HOW we did it was pulled from that purpose.
Although it was not apparent to me while we did it, I’d like to thank Simon Sinek for the guidance of his quote: “People don’t by WHAT you do, they buy WHY you do it.” Q.E.D.
Pull Value Using Feature Injection
Chris Matts and Liz Keogh developed a technique that I learned from Liz in a BDD tutorial (she’ll do another one soon near Berlin). It’s called Feature Injection and it’s a way to pull valuable capabilities and features from your vision and goal. Without realising it, we organised our sofas according to the intended capabilities of ALE2011:
- ALE2011 should create learning and sharing experiences (program sofa)
- ALE2011 should reach out to and integrate local communities (community sofa)
- ALE2011 should encourage practitioners to come to Berlin and share experiences (participants sofa)
- ALE2011 should invite participants to bring their families (spouse and kids sofa)
These sofas self-organised and pulled the features they needed from these basic capabilities, like (taking the program sofa as an example):
- ALE2011 should have short invited talks by speakers from many countries
- ALE2011 should have an Open Space on every day without anything planned in parallel
- ALE2011 should have lightning talks with topics submitted by all participants so that everyone prepares something to share
Implementation of these features was highly incremental, similar to a software team pulling stories from these features into development.
Balance Commitments using Real Options
Together with Olav Maassen, Chris Matts applied Real Options to Agile. I had heard and talked about it for a while (especially during the development of the LeanProcrastination idea), but ALE2011 organisation let me truly experience it first hand. We had no other chance.
Because of the short timeframe of organisation (less than 4 months) we had to find a venue fast and commit to a contract early, binding us (thanks to agile42 for taking the legal responsibility for this) to pay 48k€ on August 8th. The hotel was agile enough to adapt these conditions to our options, as registrations and especially payments came in much later than expected. For nearly two months, until the end of August, we did not know if we would break even.
Because of this, we had to be careful not to commit to any other additional costs too early:
- The hotel’s internet connection,
- A dinner for all,
- More rooms for Open Space
- Technicians videoing all the talks in professional quality.
Yet, the fact that we were not able to commit to “standard features” lead to the emergent discovery of new options that wouldn’t have happened any other way:
- The amazing guerilla internet connection,
- The Dinner with a Stranger,
- Open Space in two big rooms instead of many small ones,
- A professional cinematographer who is now editing videos of the conference.
The surprising outcome is, apart from our great product, that we now actually have some money left over.
Distributed Cognition, Avoiding a Backlog
We did not keep a backlog. We used Mindmeister, Basecamp. Twitter, email and Skype to communicate, and Google Docs to gather knowledge. I’ve been getting more than 1000 mails a week during the last months, just to give you a feeling (that includes Twitter and Basecamp notifications). We wrote down what we discussed and only decided what to do in the last responsible moment.
That led to a few mistakes (we informed people who had submitted a talk that was not chosen for the program far too late, for instance—sorry!) but in the end I think the experience would have been much less interesting and new had we wrote down what we wanted to do far in advance. Committing to a backlog is a decision that’s not so easy to change, especially with 40 volunteers working from that list. Continually communicating ensured that were reminded of important features, decisions and tasks on time (in most cases) and with the best available information, leading to better informed decisions.
We paid with a few mistakes and increased need of communication, but we earned a more creative, unintended, emergent result which delighted our participants. I think it was worth it!
Real Options again:
- Options have value,
- Options expire,
- Never commit early unless you know why.