Retrospectives help teams to learn from their experiences and improve continuously.
Nadja Macht, Flow Manager and Coach at Jimdo, educates and coaches native speakers of different languages on facilitating retrospectives, enabling teams to do retrospectives in their own language.
She also coaches teams on how to use Kanban to visualize and manage their flow of activities and on finding ways to innovate.
Earlier InfoQ interviewed Magdalena Bethge about fostering and growing a culture and Fridtjof Detzner about scaling and continuous improvement at Jimdo.
In this interview Nadja talks about how to balance flow and slack time in teams, doing visual management with Kanban boards and deploying agile retrospectives for continuous improvement.
InfoQ: What do you do in your daily work?
Nadja: My daily routine differs a lot, depending on current events and what is important for the teams or individual employees. Of course there are a couple of tasks which frequently occur like preparing and facilitating retrospectives, workshops or meetings. In the end my daily routine is mainly built around conversations.
InfoQ: How do you support the teams at Jimdo?
Nadja: My intention is to help teams as well as individual employees in progress and continuous improvement. Jimdo understands itself as a learning organization and expects from its employees to learn from former experiences and to improve continuously. To ensure this I introduce and facilitate retrospectives wherever necessary.
When I started in this role I was the only facilitator at Jimdo. Fortunately my team grew during the last months and I decided to educate new facilitators in 2013. With the help of Arne Roock I trained the first facilitators among our colleagues. In the beginning we introduced retrospectives in the Tech Teams and later expanded the format on to the whole company. Currently we have 9 Country Teams in Hamburg which are responsible for the marketing, translation and support of our product in different countries.
Through the years we noticed that having a retrospective in your native language provides a higher value for the attendees and that’s why we decided to educate primarily native speakers of different languages in the second step. Another benefit is that teams look for facilitators in different teams or departments which increases the understanding and communication between the teams. It also sensibilises for needs and problems of different teams from different business domains and increase the tolerance for diversity. Nowadays, as a result of having about 30 new facilitators, who speak a variety of different languages, I facilitate far less retrospectives than in the beginning.
In order to increase understanding and alignment I share my insights through workshops and trainings about Kanban, communication, collaboration, moderation & meeting practices or about leadership.
In my historically grown role I'm allowed to be part of a group of people at Jimdo that works on organizational development topics and I really appreciate that.
I want to contribute to creating and developing an environment for people to grow in. Jimdo is a value driven company and in order to keep this, the company once wrote down it's values to make them visible and share them with the whole team. Currently we're reviewing these values because the company has gone through some changes and the priority and / or content of the values has evolved.
I strongly believe in the worthiness of relevant and valuable feedback for personal development and together with our Feelgood Manager “Magdalena Bethge” I created a peer group feedback format to provide resource orientated and valuable feedback for everyone at Jimdo.
Besides that I'm available for the teams in my role as sparring partner or coach and in case of conflicts I offer moderation. I'm also one of the team members to support others in Kanban usage and questions. Kanban is the term that references to the old interpretation of my current title. I don't manage flow at all, actually I support my workmates to achieve or improve their flow.
InfoQ: Can you elaborate on what you think "flow" is and why it is so important?
Nadja: For me the magic term 'flow' is more based on learning and understanding than it's based on how fast we can move a ticket from the left to the right. The biggest trap is to improve the flow locally in order to increase the velocity of one team. From my point of view all purposes of teams are connected, what matters is aligning them. Our goal is to get everyone on the same page, to enable the employees and to make the right decisions at the right time. That doesn't mean speed is not important, but through velocity you do not necessarily increase innovation and that's one of the biggest challenges we‘re facing. To be innovative we need slack as well as getting things done.
With the things I'm doing I try to address different levels of flow: the personal level through reflection and learning, the organizational level through a culture of continuous improvement and the product or service level through helping teams getting things done while having time for innovation.
InfoQ: Can you give some examples of how teams built in slack time and how that helps to innovate?
Nadja: Teams are definitely different with respect to building in slack time, but the basic idea is similar for every team. All of our teams work self-organized and on their own authority. They decide within the team where to invest their time appropriately, when to start or when to go on in a sprint. The term “sprint” describes a period of time at or away from the office where teams are working focused on certain topics, tasks or milestones.
Our teams have the opportunity to go on in a sprint whenever they think it’s necessary to create a work atmosphere that allows them to combine focus and slack time the way the need it. Therefor we have a work location in Cuxhaven and one in Hamburg close to the office.
We have the casual friday every week that starts officially with breakfast for the whole team.
On this day our colleagues are allowed to change their focus to less productive things like learning, gathering new ideas or do prototyping for subjects that will become relevant in the near future. Some of our teams, mainly development teams, use it frequently. Others prefer to work and be productive nevertheless.We have the luxury situation that we are building our own product. That’s what makes it easier to decide on bigger feature launches in consultation with the teams. We tend to have negotiable release dates and not deadlines. That is an advantage and an important precondition, because teams wouldn’t use slack when they don’t feel comfortable with that.
Besides that we try to create a work environment that supports employees to switch easily between different working modes. At Jimdo you don’t necessarily have to work at your desk.
All these conditions do not automatically lead to more slack. The teams certainly feel the pressure of the market. In order to reduce this feeling they tend to focus on productivity.
With our coaching efforts on self-organization and visual management we do not only address productivity or velocity but try to talk about slack as well to find a good balance between productivity and slack.
InfoQ: Visual management is a way for teams and the people they work with to plan and track activities. Do teams at Jimdo use it? How?
Nadja: The teams at Jimdo and even our chef Sam uses visualization to create transparency about what they’re currently doing. The levels on which our teams use Kanban or rather how they visualize varies a lot. The Kanban walls are owned by the teams and primarily they decide how the boards are designed or structured to provide value. The teams are very different and so are their boards.
InfoQ: When boards are so different, isn't that a problem when teams have to work together? Wouldn't it be much easier for everybody (teams and their stakeholders) to standardize the boards?
Nadja: Since the moment that I started working for Jimdo I’ve never experienced a situation where
- if necessary, explaining a board was a big deal.
- to adjust the design of the board was a big deal.
- to talk about the worthiness of a board was a big deal.
Through using Kanban the boards are somehow standardized and recognizable. We use Kanban outside the development teams as well and that helps to create a common understanding.
Although the purposes of our teams are connected they are different and the teams work differently, to force them into a fixed pattern doesn’t feel very valuable for me.
The needs for boards and the level of abstraction or transparency differs between teams based on their purposes. For example, our ‘Country Teams’ want to know from a Development Team whether a feature will be released in the next days or not. And they want to know something about the feature set, because they have to prepare press articles, campaigns and support work. But the Development Teams don’t need informations about the Country Teams’ work, because with the exception of translation their progress doesn’t depend on the Country Teams.
InfoQ: You have also facilitated many agile retrospectives at Jimdo. Can you give some examples of how these retrospectives are done?
Nadja: To this day I facilitated more than 200 retrospectives and even started to train and coach new facilitators. For the retrospectives I use the structure that Esther Derby and Diana Larsen provide in their book 'Agile Retrospectives - Making Good Teams Great'. It has always been very helpful, that's why I taught our new facilitators according to this structure.
With retrospectives we actually educate our employees in problem solving, we improve their communication skills and their decision making processes. Besides that we treat them as experts of their problems and thats one reason why they feel connected and responsible for their topics. At the end they do not only improve their outcome or processes, but also collaboration, personal relations and in addition: All these things help them to deal with difficult situations.
1) Set the stage: let people arrive in the room, find focus and hear 'every Voice' as well.
For me the phase is important because if you don't address trust you run the risk that it can decrease. It is also useful to develop young and inexperienced teams because they share a lot of little private insights that lead to a better understanding of each other.
Personally I like to start with stand up exercises, because of the activity level and the strong emotional connection to own experiences.
Example: How do you feel in relation to the high number of support tickets? Left corner of the room = I feel fine, right corner: I feel terrible and overtaxed.
2) Gather data: to collect the informations about the past iteration or any period of time.
Jump to conclusion is a trap even for experienced attendees. The more different information about a problem the better. In this phase surprisingly a lot of issues rise up. Even if everybody assured you before that there is nothing to talk about.
Openness and a curiosity are helpful attitudes and this phase provides a safe situation to learn both. In case of early judgement I talk with the attendees about the Prime Directive from Norman L. Kerth.
To gather data I tend to use prepared questions that help to collect information, but also go one step ahead by asking for a change of the current perspective e.g. with circular questions.
Example: 4 L's What did you learn? What did you love? What did you lack? What did you long for? Additionally: What would the other teams tell me?
3) Generate insights: to converge the information, increase the understanding of what happened and to learn from the past.
In this phase the team has the chance to learn and to develop as a team. That doesn’t necessarily mean that all team members have the same opinion about what happened, but they are on the same page. Generating insights is important to work towards a solution as one team and to share knowledge between several team members. By the way team members learn more about how they behave in certain situations.
In this phase I really tend to improvise questions and exercises based on the previous results. But what I always do is to let the team identify what's most important for them and how they want to continue.
4) Decide what to do: let the team decide activities to improve and change.
The formal goal of a retrospective is to decide activities that contribute to the development of the team and result in business value.
I let the team decide actions or tiny experiments they can do until the next retrospective or until they achieve a certain goal. In big teams I split the group in smaller teams and give time to discuss suggested solutions which they present afterwards to the whole team. For every action item I ask for someone who takes the role of a godfather for the subject, but meanwhile most of the teams are so experienced that I don't need to ask. In case they have problems I like to ask for the smallest imaginable experiment they could do to get a little bit closer to a certain goal like in the Delta Method from Alistair Cockburn.
5) Close the retrospective: close with awareness and appreciative for the team.
Let the teams appreciate the collaboration during the retrospective or letting them say “thank you” creates a positive atmosphere and to remember the retrospective as something positive. Usually I connect the appreciation with a question for feedback or the most important learning. I like to do that with a short flashlight round to close again with every voice.
InfoQ: Can you tell us about the benefits that teams have gotten out of doing retrospectives?
Nadja: It left a lasting impression when the support team creates a model of escalation levels with the collaboration of about 20 team members out of a retrospective. In the end no one of the supporters had to work extra hours during the peak season.
In my experience the biggest benefits are the teambuilding and communication aspects of retrospectives. Because the teams steadily improve their communication skills and their decision making processes through all the small changes. Next to that they learn something about their team member’s needs. They constantly become more stable and more secure and faster in making decisions as a group. A benefit that helps when things screw up, when teams have to work under pressure and when a situation becomes difficult.
Often the outcomes are smaller changes like a different stand up time or new pairing experiments. When they recognize processes which are impeding them, they tend to identify and talk about them in the retrospective and adjust them afterwards. We have teams that institutionalized internal education and knowhow transfer to work on the same knowledge level.
Our chef Sam and his team adjust their board and the cooking sequence to make sure that their guests can estimate how long it will take and that they will get their meal more rapidly.
About the Interviewee
Nadja Macht (34) from Hamburg started working in the internet sector in 2002. After education and six years of freelancing as an independent webdesigner she decided to accompany Jimdo as Flow Manager and Coach. Since 2011 she is also part of the organizational development team at Jimdo, that faces the challenge to scale the value driven company sustainably.
