Is politics agile? Hardly. Can politics benefit from an agile mindset? I don’t know, but I’m running an experiment. Besides working as a developer and doing some open source coding (which is what I usually blog about) I’m also a part time politician (for the greens in the municipality assembly of Huddinge, in Stockholm county, Sweden). If anyone’s up for a political discussion, I’m into it, but this post is not about it. This post is about an effort I’m doing to bring some of the Agile mindset into politics.
In a municipality in Sweden, there is the municipality assembly, the municipality executive committee and a number of committees for various purposes such as school, preschool, social care etc. For all of these, there are MASSIVE amounts of decisions to be made, with even MORE MASSIVE amounts of background material. For a single meeting with the municipality assembly, the pile of paper to read is often about 10cm thick. In this massive pile of paper, there is often some interesting details that we in the green party would like to somehow act on. When we get the pile of paper, there are two questions that we need to answer:
- What things do we want to act on?
- How do we best act on those?
When we have got all the material, we have an internal preparatory meeting where we discuss those two questions. When I first joined those meetings, I found them quite inefficient. So I suggested that we tried another way of working – and brought Trello to help.
Distributing the Reading Burden
The first thing I noticed at one of those preparatory meetings was that even though everyone present were expected to have at least skimmed through the material, most people hadn’t. In some cases several people had read the same issue and there was a great discussion. In other cases nobody had read the material and we had 5 minutes of “eehmmm” and “hmmm” while people were trying to skim through the material and make up an opinion. Neither efficient, nor effective. It would be much better if there were always at least one person that had read each issue in depth before the meeting, that could brief the others and suggest what we should do with it.
I felt it would be much easier if I can focus on a few select issues in detail and know that others focus on other issues. This is pretty much like any agile software development effort. I pick a user story and work with it, while my coworkers work on other stories. In software development the coordination is often handled with a scrum/kanban board, so I created one in Trello for us. Actually, I create a new one for each meeting cycle. When I first create the board, everything is placed in the list “Unread”.
When someone starts reading an issue (a single issue can be several hundred pages) it is put in the list “Reading”. So far it looks like any Kanban/scrum board.
Done is Discuss, Act or Let Go
But next, there’s a difference. When done reading, there is not one done column, but three.
- Discuss
- Act
- Let Go
When the issue has been read through, a description is entered that is a very brief summary of the issue. It is often not only the summary from the material, but a custom summary that focuses on what matters to us in the green party. Unsurprisingly, there are often important details buried on page 34 (or similar), that most people never bother to read. Based on that summary, the person having read the issue will classify it.
If there are things that we need to discuss, there is a separate list for that. Basically it means “I’ve read it, but I want your opinions now”.
If the issue is something we want to act on, such as making a small speech in the municipality assembly it is placed in the “Act” list.
Finally, there are a lot of issues that are fine as they are. We either agree with the suggested decision, or the matter is trivial but have to be brought to the municipality assembly for formal reasons. Those are placed in the “Let Go” list so we can focus on other things.
Important Features
Except the basic functionality of grouping things into lists, there are a few other features that we’ve found useful so far. I’ve already mentioned that the one having read the issue should write a summary for the others. There’s also the comment functionality on each card that serves as a basic discussion thread.
But what has shown to be more useful, is the attachments and possibility to share photos. For construction or real estate issues someone in the group often goes to the location to get a personal view. With the Trello app in the phone, it is trivial to take a few pictures and add directly to the card. It is also often very useful to add map snippets, to allow others to quickly find out where the location is situated.
We’ve also started working with copied cards. The same issue is often handled first in a specialized committee (e.g. school committe), then in the municipality executive committee and finally in the municipality assembly. If an issue have been discussed previously, we copy that card instead of creating a new one, to retain the work done.
An Agile Mindset
So far I’ve just described the mechanics of the board, rather than the mindset and agile perspective. While a Trello board is a great tool as it invites cooperation, it must be accompanied with an agile mindset to work well.
The first and obvious step is that we can share the burden of the work. It actually works even though not everyone is on board (pun intended) yet. Those of us that are can make sure that we are reading separate issues and sharing the burden between us. With the summaries in place, the board becomes a valuable source of information for others, that can hopefully make the leap to start using the boards themselves.
Another core value of Agile that is brought in with this way of working is trust. We do trust everyone in the group that has read an issue to make the decision themselves if we should act or not. So far, most issues end up in the “Discuss” list to get a second opinion, but it is perfectly ok to make a decision right away. Related to trust is also the fact that issues are self assigned. There is nobody telling you what to read, it’s up to yourself to choose what to put effort into reading.
Finally I think that this is a way to open up and get everyone involved. Actually, those having been the most active on the Trello boards so far (except myself) are not even members of the municipality assembly themselves, but party members that want to help.
Will it Work?
So far we’ve been using this for a few months only. I hope it will work in the long run, but we need to get more people of the group actively involved for a long term success.
I’m also still struggling with how to introduce the notion of retrospectives and continuous improvement to the group. I know that we can get even better together, so I really look forward to introducing a continuous improvement mechanism, but I haven’t figured out how to do that in a good way yet.
Hi Anders, what a great achievement! As for the retro’s: I suggest you just organize it with your peers. A brief explanation should be enough, then hand out the sticky notes and ask your assembly members to participate. Once you choose to improve on the item which received the highest number of ‘votes’ your assembly members will gladly follow up in future retrospectives.
It’s a bit like starting out with retro’s in a new agile team. Just do it!
Anders,
I found your post while looking into whether flexible, requirements-driven methodologies could be applied to politics. Good software development aims for both flexibility and stability and I wonder if it could be relevant to policy making in a fast moving world.
Did you get any further with your experiment?