Using scrum in the production of techno-social commons within Transformap

TL;DR: Transformap has started using the scrum methodology 3 months ago, with focus on supporting and planning the development of the socio-technical infrastructure of Transformap. The first sprint was 6 weeks long with a team of 5 people, the last one 2 weeks with a team of 6. The process is quite and adaptive, allowing space for reflecting and improving the process on each iteration. Everyone is welcome to enter a scrum team by joining the sprint planning meetings. There is some work to do to make scrum a more convivial and useful tool for Transformap, fitting to the political and cultural specificities of its communities.

Transformap counts since September with a small team of technicians and academics, which work following the agile management methodology of scrum.

The idea was first brought up to the Transformap meeting in Munich, on June 2015. There, I (attempted) to explain why I saw scrum as a valuable tool to bring the production of Transformap, a socio-technical commons, forward. Most importantly, it was presented as a way to bring people with different skills and areas of interest to converge and work together in small teams with a clearer vision or purpose about what to develop, organise, produce.

Using scrum in the context of Transformap - sketch presented at the Transformap meeting in Munich, June 2015

As such, where the circles already provided structures for the governance of Transformap within a sociocratic framework, scrum came to provide a further layer of organisation and cross-polination across communities, languages and knowledge, paving the path for a more intense collaboration in the production of the Transformap socio-technological commons.

At the Solikon, a first planning meeting, giving place to the first Transformap Scrum sprint and breeding the first team, with Adrien, jon r, josefkreitmayer, Michael Maier and myself. The first scrum came together with the emergence of turbulent times in Transformap: pending conflicts with representation, contracting and governance of the Transformap commons were brought to surface and risked to throw away the efforts of the first days of work of the scrum team, and, more severe, the nearly 2 years efforts of all the people and organisations which came together to think and do Transformap.

The team underwent a long process of reflection, which massively affected the work it had planned, but it kept together, further planning, developing, organising, communicating with the community and reflecting. It is now finishing its third sprint and we thought it is about time to intensify the exchange between the scrum team and the larger Transformap community, improving how we work together, maybe also inspiring others to join this or other scrum teams.

What is scrum?

The emergence of scrum appears in relation to the breakthrough of Agile as project management framework (see e.g. the Agile Manifesto).

Scrum is a methodology which focuses on:

  • planning and working towards the needs of the user which benefits from the product. These form the user stories.
  • joining in small (4-7 people) teams, ideally with multiple areas of expertise. These teams are product-oriented, autonomous and self-organising
  • doing small steps (iterations) at a time (2-6 weeks). These are called sprints
  • reducing the complexity of things to be done to a level that can be grasped by the team within the iteration. That means being able to segment _epics _into smaller stories, which can get done by the team within the timeframe of a sprint.

It is beyond the purpose of this article to explain how Scrum works in detail (see references below for further reading), but a few concepts are worth mentioning.

User stories

User stories are the central element which shapes the action of the scrum teams. It contains a wish, a feature request, a deliverable which is described from the perspective of the end user.

As an example, I have formulated the user story leading to this article I’m writing now in the following way:

As a member of the Transformap community, I want to have some introduction to this scrum stuff in Transformap, in order to understand what the hell they are doing and why is it relevant for Transformap.

Some stories also have acceptance criteria, which is a list of things that should be checked out before a story is done. Upon completion, stories should provide a qualitative improvement, such as a new or improved (working) feature, a better workflow, etc… To complete the stories, a set of tasks are usually defined and added to it by the team during the sprint planning meeting.

It is important to keep in mind that a user story is not a task, but rather departs from the perspective of the other part, brings an increased value to it, and has therefore a higher level of complexity.

Story points

Story points are subjective and relative estimations of the effort or complexity of the user story. They are collectively estimated during (or before) the sprint planning meeting and oblige reaching consensus on a number by all the team members. This number represents a common understanding about the effort the team will need to put to complete a specific story.

It is during the process of effort estimation, that the meaning of the story is explored and the work needed becomes listed in tasks and understood by the whole team. Tools such as the planning poker can be useful in supporting and making enjoyable these assessments, both on offline and online meetings.

If a story is too complex and involves too much effort, it is called an epic. An epic is a story which the team considers impossible to process within the time frame of the iterations. To deal with it, we recur to trimming: splitting the story into smaller ones, still capable of generating value to the user.

Backlog

This is the first place where all user stories land. Anyone can add stories to the backlog, but no one is allowed to work stories which are on the backlog, as long as a sprint is running.

The stories in the backlog are sorted out according to priority, agreed by the team during the sprint planning meetings. New stories can be added to the end of the backlog at any time, by anyone from the team. However, they are not discussed or prioritized until the sprint planning meeting takes place.

Sprint

The sprint is an iteration in the development of a product. Lasting 2-6 weeks, it aims at completing a set of user stories the team commits to work on and bring with it a qualitative improvement on the overall product.

During the sprint, only the scrum standups and possibly one review meeting take place. Otherwise, everyone self-organizes to grab her tasks and communicate with others in the team as needed.

An important feature of the sprint is that it forces the team to focus on what it collectively decided to be the most important to work on. It focus on completing and successfully delivering (marking as done) stories by the end of the iteration.

Meetings

Scrum follows a simple, but strict workflow of meetings, which repeat on each cycle.

  • Backlog preparation (adding stories, grooming)
  • Sprint planning: a 4-8 hours meeting (depending on the length of the sprint) used to prioritize stories, discuss and refine the tasks to be done on each story, estimate effort points (we are using planning poker for that) and decide which ones we will take into the sprint
  • Scrum standups: usually they consist of daily 15 minutes meetings. We are doing them online twice a week and they tend to last 30-45 minutes when the whole team comes together
  • Sprint review (when needed, in the middle of the sprint)
  • Sprint retrospective: usually a 2 hours meeting, where the team answers to three questions, which simply ask: a) what went well, b) what went wrong, c) how can we do better next time

Tools and places

To support the management process and the overview of the sprints, we use the taiga.io web platform for agile project management. Our project is currently on https://tree.taiga.io/project/transformap/ and is publicly accessible.

Furthermore, we use pads for taking notes and collaborating on documents in progress (until recently etherpads, more recently we deployed and started to use hackpads). To archive these documents and communicate with the larger community we use of course the main channel of Transformap: Discourse. And we are also actively working on having workflows that allow us also to reach those who read e-mails on the Transformap mailing lists but are not frequent users of Discourse.

Why and how we use scrum in Transformap?

Lets start by reviewing one of the proposed shortest description of TransforMap:

“TransforMap is a socio-technical architecture (or infrastructure) to visualize local alternatives to the mainstream” – @Silke, 2015/06/16

The description suggests, and with reason, that although it aims at visualizing local alternatives to the mainstream, it i_s _a (commons) socio-technical architecture (or infrastructure).

Such a venture requires coordinated efforts. A lot. It needs planning. But traditional project management has highly been shaped (and helped to shape) to hierarchical models of organisation. Nevertheless, these have been, in the last decades, largely challenged by grassroots political movements, as much as by corporations and start-ups, especially those related to the digital economy.

This contrast of values, but similarity of patterns between a process-oriented grassroots organisational culture, and the production-maximizing agile practices in the digital industry, provides an ideal dialectic space for the emergence of new practices and patterns of communication, collaboration and co-production.

The hybrid socio-technical nature of Transformap further amplifies this tensions. Geek sees noob coming and thinks “oh no, not again, he probably just forgot to plug in the power”. Or, noob talks with noob about the geeks: “Those funny guys sit all the night on the basement, and when I asked them once what they do, I only understood the words computer and internet, nothing more. Have you ever seen them, at all?”. But of course, most of all, it is the political economical nature of Transformap’s ambitions which makes it a particularly attractive and fertile ground for pushing forward

“… our discursive space to deeply map economic narratives.” - @transformap tweet, 2015/07/10

We are now talking of discursive spaces and mapping of economic narratives. How do we expect to translate anthropological and political narratives into machine-readable semantics capable of entangling multiple narratives and again translating it in a way which makes sense to the specific narrative of the viewer? Only a process involving a people with different fields of expertise working tightly together can address the complexity of the effort. Only a process transparent and permeable to the communities who want to map their economic narratives can have the legitimacy of calling itself a commons.

The scrum team currently working for Transformap is very far away from achieving this process. But it started to do some steps. Some small, some bigger. We managed to collectively agree and find a balance between short term developments (e.g. integration with OSM) with long term visions and developments (e.g. semantic web), not only as an internal team process, but rather as a process of intentional and intensive exchange with the Transformap community.

Always on small steps, exploring a largely unknown road. Caminando preguntamos.And with the way, hopefully inspiring others to join on the way.

But we also have many doubts and questions and are always happy when we see you, the community, talking with us, asking things, criticizing, giving suggestions, gathering a circle to supervision the governance of our actions. Especially these circles, the Transformap scrum depends on them as the legitimate deliberative structure of Transformap, operating beyond the scrum frenzy. Who else could define the roles and boundaries of the scrum team, if not the circles?

Challenges ahead: towards a convivial agile?

Agile and scrum have emerged as methodologies not only aimed at reducing hierarchies and self-determination of workers. It’s main motivation is rather a productivist one: on one side it aims at increasing team work and cooperation across different skills/disciplines, while on the other hand pushing the team, as a whole, to increase its speed and the burndown rate of story points.

We will need therefore to adapt the methodology itself as experience accumulates, if we are to succeed in creating a better tool for the development of socio-technical commons supporting the new emerging economies and politics. Nevertheless, scrum as a base framework and departing point for our (self-)organisation appears to be a valid and successful choice. Scrum has short iteration and adaptation cycles, where not only the team dynamics, but the practical implementation of the methodology itself can be questioned. So, what we are doing is using Scrum, and by using it, reflecting and criticising its workflow, in the attempt to progressively build something better, which we and others can use to promote social change.

Furthermore, the language used in scrum often leads to disconnection from the community. The terms and logic of the process have emerged from the industrial and IT sectors. As such, the gap between the Scrum language and the cultures of the communities of people engaged in projects for alternative economies and social transformations needs to be bridged.

Some terms have already been emerging from the experiences here and elsewhere. For example the terms promenade or (peripathetic) walk have been suggested to replace sprint, and its transmission of urgency which promotes stress and transmits a productivist image.

Using community stories instead of user stories emphasizes the process of building stories together with and by consulting the communities. For these community stories to be truly expressing the community needs and narratives, we need to put more effort in working with the different communities related to Transformap, and helping them to shape their own community stories, which are to land on the backlogs of the Transformap infrastructure production.

With time, we should build our own vocabulary, workflows and practices for agile and scrum, shaped by the grassroots communities we are part of, according to our own patterns and culture. Transformap will hopefully contribute to the emergence of new tools and workflows for a convivial management capable of fostering the co-design and development of socio-technological commons.

Further information

1 Like

We were of different opinions about the intervals, right? And we forgot one thing after the first Scrum, as it was just a test:
To evaluate if the methodology is even suitable and conforms to our working styles.

We just reificate it without questioning now.

Referring to the retrospective-harvest, there was quite some positive feedback on the standups and their intervals.

  • Attendance at least once a week would be really good.
  • There is no quesiton, that not all of us will be able to make it all of the time, but that is fully OK. Report in the scrum pad would be very helpful The last iteration, we also had it that way and it worked quite well.