Vivien’s Travel Update

IMG_0607

Thoughts en route:

I am considering what it is I want from a trip as extensive and full as this one.

Madrid, London, Berlin, Amsterdam, Strasbourg, New York, Rhode Island, Washington, Boston and San Francisco.

Information will flow I am sure,  information on what others are doing, what steps and processes they are using, how they raise money. Meeting people and introducing Loomio will happen too.

Are these things enough of a reason for such a huge journey? I find myself thinking about opening to possibility, possibility of deepening relationships, possibility for opening opportunity, possibility for the unexpected to arrive on this journey.

I would love to meet people who have created successful scalable online social enterprise, who have thought through business models and identified ethical approaches to funding .

So much potential in NZ is limited by the piecemeal social enterprise sector , the lack of government action, policy or even interest in investing in this powerful new form of economic development. In NZ we have enthusiasm and ideas, start ups and enterprises but we don’t  have the conditions to thrive, not policy, not funders, not an engaged investment sector, nor a risk taking philanthropic sector.

So Loomio needs to play in an international space where some of these elements are already in place, where there is commitment and conviction about the role of social enterprise in finding new approaches, and technology to  create new outcomes in our world.

Where people are engaged right now in re-visioning , renewing and co creating what business, wealth, and economics mean for us as a world and global community for today a tomorrow.

This is the possibility that excites me the most, the idea of being part of an international community who knows our name and who sees the power of collaborative decision making.

Letting in the possibility of Loomio itself is perhaps the internal journey that this world trip provides space for.

A world where anyone can participate in the decisions that affect them. Truly what would this take?

A belief that many people thinking together will make better decisions than an individual will.

A commitment to a powerful sense of self worth in every person on earth, that their view is important, their Experience valid and their voice critical, especially in those decisions that most directly affect them. .

A strong movement of people bringing momentum and energy to  new ideas of citizenship  and what participating as a citizen could look like in this technological age.

I am struck by the idea that Loomio is already part of this story; the trip an opportunity to ensure we do our part well,  that we see clearly enough and dream big enough to connect all the pieces of this movement.

Creating from possibility opportunity.

Creating from opportunity  dreams.

Creating from dreams our dreams made manifest.

***********************************************************************************************

If Only Everyone Would Act Like They Owned the Business

A key principle for Loomio has been growing and developing in ways that live the change we want to see in the world.

Loomio has been around for 18 months,  and we have smoothly survived those first tricky 3, 6, and 12 month danger zones for any start up. I can feel inside myself a growing sense of confidence that we can actually succeed at inventing a horizontal collaborative organisation whilst simultaneously launching and growing a sustainable SAAS.

The women’s movement and collectivism has had a strong influence on my life, the ways I think about power and powerfulness in particular, but so has 20 years of traditional management theory and practice.

In this context I felt if any part of Loomio was important philosophically but perhaps beyond us practically, it was the goal of distributed management and decision making. After all, would it be timely, and efficient? How would we manage the inevitable interpersonal tensions and of course the risk of underperformance and good employment practice.

The cynics among you will say it is still early days, there are only 15 of you, wait till you scale, and you may be right. But I am feeling increasingly amazed by what we have achieved so far. Celebrating success creates more success, and most start-ups fail because relationships fail. Both these things make it really important to celebrate what Loomio has achieved so far in creating our version of a democratic and engaged horizontal organisation.

  • The legal structure is serving us well. Loomio is a Workers Cooperative, apparently the only one in NZ at this time. Every person employed by Loomio will be on a pathway to becoming a Loomio shareholding member.

  • I cant tell you the number of times I have been involved in conversations with other senior managers about staffing challenges and wished aloud that people would ‘act like they owned the business’. The amazing thing is that until now I have never really understood that this is a serious strategy; that staff sharing the ownership of upsides and risks in business is a real possibility for everyone! This idea seems to challenge strongly held ideas about a managerial class, and judgements about the unequal value of contribution.

  • The experience of Loomio through two intakes of contributors (employees) into members (shareholders) is that people are excited and honoured to be invited and immediately step up into a new more self-initiating way of being in the organisation and on behalf of the work we do together.

  • At Loomio we have identified performance as a team concern measured and reflected on weekly or fortnightly in the product and design scrums and the business development processes.

  • Every member and contributor at Loomio has a Steward whose job it is to clarify the persons emergent high level outcomes, and then support that person to succeed in achieving them. The Steward will most likely not be a member of the person’s direct work team and can be approached to provide support, advocacy and mediation when required.

  • Loomio is developing a remuneration strategy that reflects the balance between equity across staff and autonomy as individuals. People employed by Loomio will set their own salary within guidelines provided by the Equity and Fair Pay Policy.

I think the thing I most want to celebrate right now in Loomio are the informal systems of support and care that are so present in the team. People step into strong clear accountability conversations in timely ways, others offer space and facilitation when there are difficult interpersonal dynamics.

Loomio is still a start-up; like all startups we manage cash flow on a day to day and week to week basis. In a workers cooperative context this involves everyone strategising cashflow dips, and adjusting levels of Loomio work and contracting work so the over all momentum remains in place.

I remember a time at Relationshps Aotearoa Inc.as CEO, when the government contract was paid 3 months late. The main risk in my mind was not paying staff on time. I managed this by mortgaging my family home to ensure no-one was adversely affected by poor government payment processes. It did not occur to me to share the problem with staff or to expect they would want to be involved in resolving the situation.

Perhaps this experience highlights the power and flexibility of an organisation where everyone acts like they are an owner of the business because they are  an owner of the business.

***********************************************************************************************

Travel updates

Madrid

Madrid was challenging for me. The environment was very structured and very male dominant. I had forgotten the feeling of being in a conversation and people responding to the comments I make to the man who can talk on my behalf. Thank Goddess Ben was noticing this as well – we just agreed he would bat the ball back. The evening session was hard, all in Spanish, plenty of deep tiredness, but also fascinating. Loads of emotional energy firing around, trying to read the emotional context was an interesting experience. Highlight – without a doubt Reyes Montiel talking about the Spanish Green Party (Equo) use of Loomio at the regional and national level. She also had good questions like:-

* how can we facilitate better so 1 person with lots of time doesn’t dominate?

* How to make it work for more people?

The next morning was completely different. Small number of us, probably the most aligned men with what Loomio is doing. I had great breakthroughs in my thinking talking with them that morning.

  1. Loomio is radically different from any of the Madrid projects because there are women involved, because we talk to people using Loomio, and because we have a diverse range of skills in the team. I sat in deep appreciation of all of you, the diverse, wonderful, skilled and conscious Loomio team.

  • Secondly, that our commitment to scale and measuring social impact also sets our strategy on a completely different path that the other Madrid initiatives. They are totally focussed on the Political. Which brings me to my third point.

  • By everyday democracy we mean building the capacity and competence for group discussion and decision making from small groups up to large groups, starting where people are at,and learning as we go. We mean building the context for everyone to be involved in decision making wherever in their lives. What I have become more conscious of is how this frame leads and guides our development in much more commercially scalable ways than if we had focussed on the political system. From where I am sitting here in London these team diversities and strategic focus have made Loomio so much easier to talk about and compelling for people to hear about. (just saying)

London

IMG_0611

Hub Westminster

This was an easy gig for us. Probably 30% of the people were supportive NZers. There was a real buzz in the room. People from that meeting are inaction in Loomio already and we have strategic follow up business meetings on Monday as a result. Customers and Channel partners were easy to spot and keen to follow up.

The main coder in the room at the Hub event was Paul MacKay, who works for NESTA and his own business Folk Labs and had great feedback for us.

Point People Dinner

Oh my goodness, Hannah did this with such class and attention to detail. I loved every minute of it, even the fish and chips! We met Kate Swade from Shared Assets who are a group working on public decision making around shared spaces, like the canals. Kate wants to work closely with us and we will be following her up as a priority. Hannah had really worked her network to find and invite exactly the right people to this exclusive, in a basement, under a skating rink mystery dinner

KPMG

KPMG in London have decided to commit to the front end of the start up scene. Set up an accessible informal team in the tech hub area of London and are building long term realtionships for long term pay back. Aimee who leads the team, just ‘got’ us immediately. She loved the tool and we discussed two opportunities to explore together. This was such an important meeting because it really exemplifies the difference in this European market to our own small and comparatively poor market. The opportunities and the interest in Loomio is palpable. What is also clear is that we have developed in a way that people see as best practice. Lots of positive feedback about our approach.

Said Business School Oxford

Cool  international representative group of men (no Oxford isn’t a men only environment it is just that only men go there!).

Nesta

Basically they are interested in social impact that will increase the well-being of British People in 3 categories, including participation and democracy. They would definitely invest in a NZ company if everything else stacks up. Joe rapidly talked through a process sort of like this:-

-Is there a problem/need? “YES”, -Are people willing to pay to fix it? “YES” – is it built based on customer feedback, “YES” , great lets move on. Joe began to think about introductions to important London agencies. We left after 40 minutes feeling deeply excited.

One day after a venture capitalist told us to stick to social enterprise but that the hard part would be finding people open to investing in an overseas company, we had found two!

For Rent: Elite Squad of Experienced Ruby on Rails Web Developers

The Story

We’ve spent the last two years building a product we’re proud of – Loomio, an online tool for collaborative decision-making.

An amazing team has come together around this vision, and we’ve invested hugely in great team process, and become a lean, mean, agile scrum machine in beautiful working order. It’s really humming!

But as a bootstrapping startup, we’re about to run into a gap in our cash runway in January. We’ve got big plans for bringing in resources around April 2014. As in-demand web dev professionals, we could each go out and get paying contracts as freelancers. But we want to stick together as a team, and because we work together so well, we can offer more value to a client together than apart.

The Offer

Rent us out! You get a fantastic highly skilled Rails dev team, ready to go. We get to stick together, and practice our craft on a new product and code base. As a bonus, you get to support an inspiring open-source project, Loomio, to carry on afterward.

We’re available from January to March 2014, and open to any and all offers from anywhere in the world. Tell us about your project and make us an offer!

How We Work

  • Agile methodology: fast iterative development, good estimates of development time. Our flat structure (Loomio is a worker-owned cooperative) ensures diverse perspectives are fed into the design process.

  • User-experience focus: all development is measured against the value we deliver to users – we consider user-experience holistically, informed through early and regular user testing and ongoing analytics.

  • Evidence-based decision-making:  measure, iterate, learn

Our Track Record

Technical Skills

  • UX (user experience) development

  • TDD (test driven development), specifically using Cucumber (translates business needs into technical requirements in a way that is accessible to non-technical people, while remaining specific enough for developers)

  • Interface design

  • Ruby on Rails

  • Javascript: JQuery and Angular

  • Responsive design

  • CSS

  • Bootstrap

  • Postgres

  • Full stack web design (including sysadmin)

  • Analytics and metrics

  • SEO

  • Comms, project management, and visual design pros on the team, as needed

We’ve got six developers ranging from senior to junior, plus comms, design, project management and more. Now we want to get excited about your next big idea. Hit us up on contact@loomio.org.

Occupy Scrum: How Sprint Retrospectives Brought us to Agile Nirvana

Loomio is a tool made by a ragtag bunch that grew out of the Occupy movement, anarchist and activist circles, free-thinking musicians and artists, open-source advocates, techno-utopians, social entrepreneurs, and collective community builders. We’re a worker-owned cooperative company with no bosses. As you might expect, we aren’t predisposed to enjoy being told what to do, having role titles, or submitting to strict rules.

Like most developers, we’d heard of the Agile Method of Software Development, and we picked up bits and pieces gleaned from blogs or conversations. But we still resisted any kind of “oppressive” restrictions on our freedom.

We just didn’t get it – the Agile Manifesto isn’t so different from what you might see in an Occupy manifesto. It says right in the Scrum Guide that Scrum teams are “self-organizing”. We were hyper-conscious of process in our general meetings right from the start, but it took us a lot of trial and error, and practice, to apply the same rigour to process in our workflow.

Turns out, Scrum is what freed us, but only when we submitted to it fully.

Embracing Scrum In Its Entirety – It Ain’t Easy!

Because we’re stubborn, we had to learn the hard way, by making mistakes. More than a few times, just as we thought something we were building was nearing completion we’d realise it was not quite right (or even very wrong). Or things would take way longer than we thought. Or people would get frustrated at the way the team was working.

We’d have informal conversations about process improvements, or just carry on building until it worked. Tasks could continue indefinitely. We had no way of tracking our performance, and as the team and project grew, we were finding it increasingly difficult to make changes. Sometimes we felt like the app was locking us in to a particular trajectory against our will.

Loomio co-founder and lead dev Jon was frustrated by this dynamic but didn’t quite know how to change it. One day, he stumbled across a video by Ken Schwaber, and was inspired to study up hard.

Jon asked for team buy-in. He asked for permission to be an asshole about it until we actually got whipped into shape and started following Scrum for real. We might be a bunch of wilful individualists, but we wouldn’t be here if we weren’t prepared to do what’s best for the project first and foremost, and we saw that this was it. All consented to some much-needed bossing around.

It certainly wasn’t easy at first, and Jon had to continually repeat the phrase “let’s stick to the process” until he was blue in the face. The main thing that Jon asked of the team, and the main take away that he got from Ken’s talk, was this: to get full value from Scrum, you must adopt it entirely, following it to the rule.

Retrospectives are the Most Important Part of Scrum

The real magic of Scrum is not just the Scrum techniques themselves, it’s that continuous process improvement is built in. You can’t do that without retrospectives.

Retrospectives are a formalised way for the the team to reflect on the sprint that just finished and discuss the good and the bad of it. It’s about resolving conflicts or misunderstandings, and celebrating the good things that happened during the sprint, with the purpose of making process improvements for the team to adopt in the next sprint.

Following Scrum process closely is hard. We found that we needed plenty of practice to get a rhythm as a team. To get good at it, we had to learn together through practice, reflection, and communication.

We developers like to think we can teach ourselves anything by reading about it on the internet. But there are some things that you just don’t comprehend without stepping out of your comfort zone, actually putting it into practice, and making some mistakes you can learn from. You cannot really understand retrospectives by reading about them on the internet (yes, we are aware of the irony that you are reading about this on the internet – go out and try it for real!).

When you’ve got a lot of work you want to get done, or you’re already sure your opinion about something is correct, facilitated processes can feel like they are slowing you down. But our experience has taught us that in the long term, they absolutely pay off.

“I usually approach any meeting with a certain degree of trepidation, as it feels like it is getting in the way of real work. However giving the retrospective the time it needs has paid off time and time again. The simple exercises you participate in as a team brings out how everyone is feeling about the state of the project. You can’t help but address the major issues in the room. Having timeboxed conversations in order of priority and finding process improvements to address issues is the therapy that the team needs. Despite initial resistance, I regularly come away from a retrospective with renewed faith in the team.” – Rob (crotchety old Loomio dev)

Sometimes retrospectives are a place for challenging conversations and confronting issues you might otherwise avoid. It’s a place for anyone in the team to say what’s bothering them. These frustrations, which might otherwise fester, can be turned into great process improvements when facilitated properly. When you have great facilitation, the group benefits from shared understanding and protocols, skill at helping everyone communicate effectively, and tools for handling conflict.

Here are some facilitation techniques that have worked for us:

  • Visual: drawing progress lines, mood graphs, walls of post-it notes, and writing up the agenda of timeboxed conversations clearly

  • Verbal: consciously deciding on speaking protocols depending on time constraints and content, to empower people with varying communication styles. Some examples are a round (going in a circle, everyone speaks once), popcorn-style (people ‘pop’ whenever they feel they have something to say), a stack (people add their names to a list and they are called in order), or other agreed protocol (such as not speaking again until two others have spoken)

  • Cultural: personal circumstances, stress and emotions are legitimate dimensions to how people work. We start meetings with a check-in round focused on personal wellbeing. We make it OK to mention issues related to mental health, family obligations, gender dynamics – whatever needs to be acknowledged. We explicitly celebrate people taking time off to rejuvenate or study new skills.

Process Improvement in Practice: Experiment, Learn, Repeat

Here’s an example of how one of our processes improved through formal retrospectives.

When we first started, we deployed code as soon as whoever was working on it and whoever else happened to be around thought it was ready. This worked at first when Jon was the only developer on the team, but as the team grew it meant that we were missing certain necessary checks. Just small stuff like making sure the UX was intelligible, and that what we’d built was actually responding to the original customer need we’d set out to address (!).

During one of our retrospectives, we arrived at the conclusion that we needed a sign-off process. In traditional Scrum, the Product Owner signs everything off, so we decided to try that. This wasn’t the final answer, though, because we found that it wasn’t always clear what criteria exactly the Product Owner should be using. We tried giving the Product Owner a check-list of criteria, but it was time consuming for them to have to chase different people around to see if certain things were done. Also the Product Owner isn’t a code or design expert, so things were still getting missed.

Next we experimented with what we called ‘sign-off parties’ – get everyone together at the end of the sprint and do it all at once. We had a senior designer as Design Owner and a senior developer as Code Owner, and everything could be verified at once without the Product Owner needing to track people down. The problem with sign-off parties was that, inevitably, problems would be discovered (a good thing) but we’d find ourselves at the end of the sprint suddenly finding out we had a bunch more work to do (a bad thing). This bottlenecking caused every single sprint to start going over.

Finally we arrived at our current iteration of the process – rolling sign-off during the sprint. Now, when someone thinks their work is ready, they send it for sign-off by the Design Owner and Code Owner. There’s a checklist to make sure it’s been user tested, QA’ed, and cross-browser compatible. By the time it finally gets to the Product Owner for sign-off, they can see that all this has been done and don’t need to chase anyone around to make sure. Deployments can happen continuously and to a high quality standard, and doing this work is incorporated into the sprint itself, allowing us to actually finish what we set out to complete by the time the sprint is up.

It took three iterations of continuous improvement to get to where we are. Of course, our process around sign-off will continue to change as we grow, but we’re confident it will always change for the better because we’ve got rock-solid retrospectives.

Roles are Key, Even if You Are All in it Together as Equals

We are a highly collaborative team making a tool for collective decision-making, and a bootstrapping startup without the resources to employ people in Scrum roles who aren’t also on the Product Team. This creates an inherent tension with the traditional Scrum roles, which call for separation from the dev team, and hierarchical authority to make decisions.

We’ve worked through this tension by learning that Scrum roles are about personas and archetypes, not the individuals who happen to be in them. In fact, many people think that cross-functional managers are ideal for Agile, and at Loomio, every member is a manager. Thinking about the roles this way has helped us optimize them quite separate to anyone’s personal ego.

We encourage all our team members to learn about the roles and support them upskilling to the point they can take them on. We rotate people through roles periodically, to share the load and the learning, and to prevent anyone from getting too dictatorial. Going out to get external training is a great way to import Agile wisdom and culture into these roles.

We’re a cooperative company, meaning we’re all business owners, so the ‘business team’ serves everyone, and the traditional Agile ‘product owner’ has had to be adapted to our context, making it a highly collaborative role interpreting a wide set of priorities into a coherent work plan.

It’s up to the Scrum Master to facilitate the retrospectives. Once Jon had the process up and running, he handed the scrum master mask onto Mix – having a flair for the dramatic, he literally wears a black zorro mask when acting as the scrum master, so that he can take off the mask and participate in discussions as himself as well, and people don’t confuse the two personas or take it personally when he invokes the powers of his role.

The Scrum Master maintains a structured framework for the two-hour retrospective meeting, and ensures everyone’s voice is heard. We get through complex discussion points with minimal friction. The scrum master needs permission from the group to be a bit of a stickler, e.g. setting time limits on conversation topics and reminding people to stick to the conversational protocols we’ve agreed to.

Since we all own the business, we aren’t working for a paying client. So the idea of having a single product owner making the final decision on what features do and do not get built took a bit of getting used to. But it’s a very essential role to include and respect, to make sure we’re setting the right priorities and responding to feedback, user testing, and business circumstances.

Our current product owner, Rich, took over from Ben when he took off to talk about Loomio around the world. Rich stays in continuous contact with the user support, research, design, development and business teams, synthesizing all of that input into a coherent set of priorities for each sprint. He’s conceived his role as a communicator across different parts of the project, and a synthesizer of all the inputs.

What We’ve Learned:

  • Adopt the whole scrum process
    AKA: “Either scrum or don’t scrum. Don’t scrum haphazardly.” Take the time to learn it for real and get good at it, especially retrospectives. Attend a few external classes. Share the job of adopting scrum amongst your team. We owe a lot to the workshops held by Boost Media here in Wellington, who hold classes on many aspects of Scrum.

  • Focus on writing good stories
    We’ve learned the importance of writing better user stories, specifying clearly the who, what, and why of each feature. When you’re writing good stories and running good retrospectives, you can really start to feel the self-organising, self-improving nature of Scrum.

  • Make your sprints work for you
    Once you learn the rules, then you can start learning to bend them a bit. We started with standard weekly sprints, but found that the overhead of sprint planning and running a good retrospective meant that we didn’t have enough time during the sprint for all of the work we had to do. We’ve since moved to a 2 week sprint and made a strategic decision to start on Wednesdays rather than Mondays. This means we aren’t pressured to deploy on a Friday – meaning we’re no longer enslaved to the project all weekend worrying about bugs and fixes and things. Only through following the process strictly can you control variables enough to effectively experiment.

  • Track velocity
    Our mentor and code-guru Craig Ambrose recommended “velocity tracking”, a measure of user-facing value delivered per week. We dropped the ultra-flexible Trello in favor of the highly-opinionated Pivotal Tracker, with velocity tracking built in. Estimation is something that we naturally get all fussed about as developers. It’s hard. The best estimations involve all members of the team looking at well documented stories, and it rapidly highlights if a story isn’t clear. Estimating shows differences in the understanding of each story, allowing us to catch it much earlier. As we improve at this, having a good idea of task sizes helps us have an increasingly accurate view of what we can achieve in the short and long term.

  • Visualise progress
    We’ve experimented with visualising the sprint on a whiteboard. This helps us check in on our progress during daily standups, increases the visibility of stagnant tasks, and helps us see who is available for pair coding. In the example at the stop of this post, we were able to note how we slipped up on sticking to the stories in the sprint and made process improvements based on that.

Do you want us to work for you?

All this could be yours. We’ve got capacity over the next few months to work on your project. Join us in Agile nirvana!

Ben’s update from Madrid and the Democratic Laboratory

Finally had time to write up the first few days! In London now, and will write up the next two days tomorrow. Miss you all very much!

Wellington–>Auckland–>Singapore–>Frankfurt–>Madrid – the first 3 days

vivien_at_hub_madrid

Having no internet meant that the 30 hours of flights gave the most time to read that I’ve had in about two years. From Wellington–>Auckland–>Singapore–>Frankfurt–>Madrid I got to read 4 things I have been yearning to read for ages:

First, Binding Chaos (a powerful treatise by Heather Marsh that feels like something John Stuart Mill or Emma Goldman might write have written if they had grown up on 4Chan),

second, a chunk of David Graeber’s Debt, the first 5000 years (amazing ethnographic approach looking at the historical and sociopolitical roots of a global economy where the major commodity is debt), and

third, The Dispossessed (Ursula LeGuinn’s ambiguous utopia about a self-organising society on a resource-poor planet where nothing is owned and everyone is free, contrasted with a hierarchical society on a resource-rich plant where everything is owned and the people are free to consume, but everyone is owned by their possessions).

fourth, Linc’s whitepaper on possibilities for fostering more startups in NZ with case studies in San Francisco and Tel Aviv (which made me really glad we’re based in Wellington, and that we’re a social enterprise not a traditional Silicon Valley nightmare)

Arrived in Madrid on Monday afternoon, and Vivien and I wandered through the streets awestruck. The contrast between the beautiful architecture (old and new) and the sea of plastic rubbish flowing through the streets because all the public workers in the city are on strike against austerity measures made it feel like the right time to be here. People keep apologizing for the state of their city, but it’s actually kind of beautiful, socially if not aesthetically – and there’s very much a feeling of a widespread understanding that the workers’ plight is justified. There’s frequent mention of ‘The Crisis’, which is very real for people here, massively affecting daily life.

After wandering and settling, we met Yago and went for coffee with two of the core programmers behind Agora Voting. An MP for the Equo party has committed to following the will of his constituents as expressed through Agora, acting as a channel for direct citizen participation in the Spanish parliament. Things are still in the very early stages, and they’re tackling the huge challenges of identity verification, encryption and security.

The Labo Democratico forum Yago organized was that evening – he organized it under the Labo Democratico banner, which is a network of people he’s pulled together with a shared interest in experimenting with new ways of using technology to upgrade democracy. Seriously amazing bunch of people. This was their second event, and he pulled in people from 4 other online democracy tools to present alongside Loomio – KuorumAgora Voting, Incoma and Appgree. All of them are focused on slightly different parts of the puzzle, and all taking innovative and complementary approaches. We had to speak through a translator, meaning breaking up dialogue into chunks of a few sentences – funnily enough, very reminiscent of learning to speak through the human microphone at Occupy.

The rest of the presentations were in Español, so we did a lot of attempting to interpret meaning through pictures. I had a guy next to me whispering in my ear when the conversation was taking particularly exciting turns – there was an intense debate about open-source vs closed source tools, and whether it was ever OK to have democratic participation through proprietary tools – then an even more heated debate about whether closed source or open source tools were more secure. It seemed that software libre came out on top :)

A highlight for me was when Reyes Montiel, an MP for the Equo party, said that Equo had been using Loomio at the national and state level, and were finding it really helpful (surprise surprise, it’s saved them from making decisions by email!).

We spent the whole next morning with Yago and the lovely people building Incoma, drinking coffee, hanging out at MediaLab Prado, and getting a much better understanding of the social-political situation in Spain and the direct democracy movement. I’m totally amazed how much such a small network of people are achieving, building these tools in their spare time. They all work other jobs, and they’re all very small teams of committed people. Even just that morning of conversation would have made visiting Madrid worthwhile – so much warmth and enthusiasm for what we’re doing, and real excitement about the way we’re doing it. Being open source and talking about building public infrastructure for decision-making online really gets through to people. Feels like we’re very much on the right track!