Can you facilitate a Coderetreat as a Scrum Master?

What is a Coderetreat and how did I learn about it?

GDCR describes a Coderetreat as “a day-long, intensive practice event, focusing on the fundamentals of software development and design, away from the pressures of getting things done”. The first time I heard about Coderetreat was while I was the Scrum Master in a development team of 8 developers continuously working on a new product that was released 6 months before. Crunch time was over and as we definitely had some technical debt already we wanted to shift our focus more to software quality and how to increase it. Back then there was the idea to start this with a team internal Coderetreat.

We got the idea from Code Cop Peter Kofler, who offered to facilitate the Coderetreat together with me. Since then we pair-facilitated many Coderetreats more. I was very glad to get invited recently as a guest in his Coderetreat facilitation podcast, where we discussed what to look for and ask about as a non-coder. This discussion triggered me to write this blog post and share my experiences of facilitation as a Scrum Master with very little coding experience.

My experience with Coderetreat facilitation

So our goal was to shift our team’s focus more towards code quality. We needed a kick-off to start the integration of hands-on training and practice to our usual working routines. Therefore it was important to create not only a safe place outside our regular work but also a fun atmosphere. A Coderetreat was perfect for this kick-off and back then we already thought about repeating it every three to six months and maybe inviting also guests.

I prepared myself by reading The Codingdojo Handbook by Emily Bache and also participated at some Randoris that were organised by some of our developers already. And of course, I read all about the format, Conway’s Game of Life and the most common constraints.

At the beginning of my first Coderetreat, I was a silent observer. Peter started with the intro, focusing mostly on the coding dojo mindset and a rough description of the Game of Life. Then we started to collect learning topics, most of them were about TDD and code quality.

During the first sessions, I had no clue what to look for. Neither was I able to follow the discussions of the pairs nor how they wanted to solve the problem. As they started writing code I could not read it and got no idea of their approach. Nevertheless, Peter asked me what I had observed at the end of every session so I had to come up with something. Then I realized that even without understanding WHAT the pairs were doing I got a feeling of HOW they were doing. Was a pair stuck with big questions or did they make progress? Did they have troubles understanding the problem or the constraint or were the already in a good flow and completed first steps? Was there some planning on paper or text files or did they start hacking some code immediately? At some point, I also recognized a bit of what was happening on their screens. How many unit tests did a pair write? Unit tests red or green? Did they start with the cell or the grid? At some point, I even recognized some repeating patterns like the use of two-dimensional arrays. I shared these observations with Peter and together we discussed what we should ask in the retrospective, how we should shape the next session and with which constraint we would continue. Especially the selection of constraints was tough for me as many of them are difficult to understand as a non-coder, there I needed Peter’s support. But I felt comfortable in the retrospectives and had some ideas for improving the setting or environment as well. Probably because these were the more familiar areas for me as a Scrum Master.

After facilitating multiple Coderetreats, I am now more comfortable with observing what is going on in the sessions. Therefore, I managed to shift my attention even more towards the retrospectives as I am doing now. What learnings or ideas do I recognize at the pairs? What should I ask so that they will come up with these topics and share them with the other pairs? How can I push the discussion during the retrospective so that the pairs participate actively and not only listen to the solution of other pairs? Somehow, I try to predict the outcome of the retrospective and to ask the right questions so that interesting topics get shared. But very often the answers are completely different than expected and this is also great! Surprises are always a good sign for learning opportunities.

It is still challenging for me to select constraints that fit the desired learning topics of the participants. Therefore I am glad to have a co-facilitator with coding experience by my side so that we can share our ideas, discuss them and decide together how to proceed. It also helps me when my co-facilitator can explain the different solutions of pairs to me or helps me realize that all of them follow the same approach. That would be a sign for us to choose a constraint that forces them to go for a different way. Pair facilitation also gives us the possibility to split into groups for the intro or the retrospectives. In a smaller group, the participants need to be more active and we can share the results with the other group afterwards.

My biggest learnings from Coderetreats

For my role as Scrum Master observation is an important skill. Facilitating Coderetreats is a great way to train this skill, especially the intense focus on coding is interesting. As a non-developer, it can be hard to understand the daily challenges of coding and Coderetreats help me a lot to improve in this area. Now I can see the crafting aspect of coding and also the broad range of different approaches and solutions for coding problems.

It is also a new and unfamiliar environment for retrospective facilitation. While you are still able to use familiar formats and techniques, the topics are very different from usual. While we tend to talk about collaboration between development and business at our sprint retrospectives, the Coderetreat retrospectives are much more about technical quality, practices and mind-set. This forces me to stay in a strict coaching role, as I am not able to act as a trainer in these topics. But again, this is a good way to learn more about coding and that helps me to better understand developers.

Another thing at Coderetreats is that there are always unexpected things that happen. Issues with the setup, participants dropping out or delay of the lunch delivery are just some of them. Surprises are part of the format and we want an open mind-set, this should also apply for me as a facilitator. So I always try to welcome these surprises and see them as a chance for learning, even if they are not wanted. Therefore I have to resist my first urge to immediately solve, remove or reject a surprising problem and allow me to spend a moment and getting fully aware of it instead. Maybe there is a good learning opportunity.

So, can you facilitate a Coderetreat as a Scrum Master?

My answer is definitely yes. It helps a lot to have a co-facilitator with experience on your side, at least for your first Coderetreat. Accept that you are feeling a bit lost, especially during the first sessions. Ask yourself what you are observing multiple times during each session. Take an active part in the moderation of the retrospectives as this will be more familiar and you will gain some confidence. Try to improve your understanding of coding and don’t be shy of reading code, you will get more used to it at Coderetreats. And be prepared for surprises, they are part of every Coderetreat.