Our feedback: Pragmatism as an agile method

A METHOD BUILT ITERATIVELY AND INCREMENTALLY

When I explain that our team builds Kuzzle following the agile approach, I’m often asked which method we use. In that precise moment, the first answer coming to my mind is: “None. After all, the first value from the agile manifesto puts people and their interactions above processes and tools.” It’s provocative, it enables to start talking. But it’s not really true.

Our team has a method of organization. It’s just that we don’t strictly follow the methods labelled agile. In our method, there is a little bit of Scrum, of Kanban and so much more. In fact, if I had to name our method I would call it pragmatism

Every two weeks, we gather to reflect on how we work. Our retrospectives are quite standard. We begin by sharing our individual experiences of the last two weeks: what went well, what went wrong and/or could be improved, our ideas and questions, and our “hearts” (1). Then we set priorities (2) on topics we want to talk about. We discuss each topic until there is nothing left to say. Then we go on discussing topics in order of priority until the allotted “timebox” has elapsed.

It’s during these reviews of events that we bring about some changes in our method of organization. When we come across a pain, we talk about it to understand the reasons. We then imagine altogether a solution. When it collects the consent from the whole team or at least none objection we set it up during anexperimental period following a PDCA.

At the end of this period we assess the effectiveness of this solution and take a decision:

• if the solution isn’t suitable, we give it up and look for another one
• if the solution isn’t optimum, we improve it according to our experience and the experimental period is extended
• if the solution is suitable, it is adopted and we add it to our team rules

We draw our team rules on a wide noticeboard posted in our working space. This enables us to share in an easy way our method of organization with new team members. When a team rule is modified or withdrawn, we update the noticeboard.

A METHOD FOCUSING ON AGILE VALUES

Our method is agile because -according to me- it is steeped in an agile state of mind:

• it is co-built by whole the team,
• it is built iteratively and incrementally,
• it only contains practices and necessary tools,
• it welcomes change and manages to adapt quickly

Our method is above all agile because our team is agile as we are heavily influenced by the values of agility: trust, openness, benevolence, self-organization, co-construction, collective intelligence, simplicity, the right to make mistakes…

These values pervade in our relationships, in our organization, in our work, and therefore in our practices and in our tools.

GROWTH CHALLENGE

Over the months, we realized that practices and tools working for 5 people are not necessarily fitted when the team increases.

Generally speaking, when the background of a team changes (size, project, surrounding organization,…) the method of the team often needs to change.

Retrospectives enable us to identify when a practice or a tool is no longer suited. We think altogether about a solution to try out.

For example, here is what happened at the end of November 2015.

A Post-it “Too many meetings” has been displayed during one retrospective. The team-member who put this Post-it explained that there were many meetings but that they were all interesting and useful. The problem is that if everyone takes part in all the meetings we have little time left to dedicate to development.

As collective intelligence is one of our values, we appreciate and enhance the fact of thinking up together.
We have several workshops:

• a workshop on community management (one hour every two weeks) to think altogether on how to interact with Kuzzle community
• and our agile rituals: review, retrospective and product management workshop (3) about 3 hours every 2 weeks

We are all watchful that our workshops are effective:

• we define/remind the objectives at the beginning of each workshop
• we set a timebox for the workshop even if it means pursuing it another day if objectives haven’t been reached
• if we finish earlier we stop
• we take care to listen to each other

A few weeks earlier, we had already improved these workshops thanks to what we have named the “Law of Two Feet” referring to the open space technology. We often tackle several topics within the same workshop. At each topic change, the facilitator announces which topic we are going to tackle. Everyone chooses to take part or not to this topic and tells everyone else. You can “leave” the workshop in the middle of a topic and come back later: you just need to inform other participants and it’s ok.

During this retrospective planned in November 2015, we went further.

We have officially decided to set up working groups when it is necessary.Therefore we make a dedicated channel on Slack (our internal messaging tool) and people who want to be actively involved just add to this channel. Part of our discussions take place on Slack and when it’s useful we seize the opportunity to organize a workshop (we set it up on a Slack channel).

As it’s important that the architecture remains the property of the whole team we have defined a new format for our Thursday design workshop. We go through all the working groups in place at the moment. Each working group shares its progress, its thoughts, its decisions and gathers the feedback from all the team members. During the remaining time, we tackle cross-design topics, which can’t be addressed in small groups.

So we have found a solution enabling us to keep our main rule of collective property architecture, while adapting to change. Including this new constraint enabled us to improve our traceability.

CONCLUSION

In my previous experiences, I noticed the difficulty for several companies to scale up i.e. to develop their organization in harmony as the company grew.

Kuzzle team is on its first scaling-up step. More and more complex challenges are awaiting us, in particular working with distant co-workers or getting organized in several teams. I don’t know yet how our organization is going to evolve to include these changes but I’m quite confident on our ability to co-construct and to try out solutions to take up these challenges.

(1) A “heart” is a message from one team member to another for something he has done or said, which pleased us / saved our life / helped us…

“Hearts” are important. We can thus make positive feedbacks because we don’t always think about it (whereas we often think about making negative feedbacks). This is our way to express that we are happy to work altogether. It’s a crucial element to upkeep the motivation of the team in the long run.

(2) To set priorities, we use the dot voting technique. Each team member has 3 dots (coloured sticky labels, felt-tip lines…) that he can share out as he wants between several topics. One person can put several dots on the same topic and we don’t have to use all our dots.

(3) The product management workshop is the development of what was before our planning meeting and our “backlog refinement”. In this workshop we all design Kuzzle product. We talk about roadmap, we might set up a storymap for the next version of Kuzzle, we prioritize the next features, we choose the following subjects that should be dealt in the design workshop…