A “Slow Code Retreat” to be less in a hurry
“Developers will always have more work than time” We can race our TODO lists or accept and slow down NOW. The “Slow Code Retreat” helps us do that!
The team is good, but the organization mainly pushes them for output!
Developers have as much difficulty changing their habits as anyone else. Besides, we’re too busy.
This manager was in my interview and kept asking me questions like: “what if devs feel they are being slowed down?”.
We all know this story. Learning new practices or taking on new habits takes time. And developers always have something more urgent to do.
Lately, my colleagues and I almost worked with a team struggling with onboarding. We helped define knowledge-sharing actions, trained seniors to run team mobs or katas, etc. Yet, at the moment of setting up team sessions, senior developers were too busy!
There is no workaround: Sustainable pace starts NOW!
In its most trivial formulation, it’s as simple as this. To go from doing A to get to doing B, we have to unlearn A and learn B. That takes time. If we don’t have time, we can’t afford to change. (Slash the Load, Mike Hill).
Teams only have so much control over their time! There are always urgent and valuable projects to deliver. Even productivity and sustainability improvements only add more work in the short term! Very often, management will not grant the team some time for learning.
Sometimes, it might look like there are no ways out!
At every moment, we have the choice to step back and take it easy! Nothing prevents us from injecting some ‘sustainable’ seconds into work. It’s not about what happens. It’s about our state of mind and how we live what is happening.
At first, it can be only a few seconds here and there during the day. With time though, we can train our minds to do this more regularly.
How to slow down at work as developers?
“Inject sustainable instants throughout our day of work” might sound a bit too vague… So let’s see how to do this more practically.
The Slow Code Retreat is a workshop I ran at XPDays Benelux. The idea is to let people experience different ‘slow working’ techniques.
Here is the feedback I received at this workshop.
Here is how the workshop is structured:
- Welcome
- Connect with the topic and other participants with these 4 questions:
- What did you say no to to attend this session?
- According to you, what could slow code be?
- From your experience, list a few situations where slow code could have been helpful.
- What is the big question you bring to this session?
- Present 6 slow code practices (see below)
- One or two rounds of slow code practice on code katas
- Participants pick 1 or 2 practices they want to experiment with
- They self-organize in solo, pairs, or mobs
- For 30 minutes, they go through the simplest katas like Fizz Buzz or Pascal’s Triangle
- One or two rounds of slow code practice on code katas
- Takeaways
- Q&A
The complete workshop lasts between one and a half and 2 hours.
6 slow working practices
Participants can try the 6 slow working practices during the workshop. I’ve split them into 3 categories: coding, communication, and mobbing.
Slow Coding
We can use these whenever we are programming solo, in a pair, or in a mob.
Slow TODO List
Take the time to focus only on the present task:
- Keep a TODO list while you code
- Keep track of everything that remains to be done
- Check or strikethrough steps as you do them
- Indent sub-tasks
- Can use a .txt, a .markdown, a shared online doc, or a mind map
- Reorganize your tasks when needed
- If you revert steps that you cannot do yet, it becomes the Mikado Method
Benefits:
- This removes all the mental load involved with keeping track of the status of work
- The map serves as a communication tool for handovers, pairing, or mobbing
- Helps us to drop things that we eventually decide not to do!
References:
Slow Baby Steps
Take the time to practice egoless programming and baby-steps programming with TCR:
- Start coding with TCR
- Whenever you get reverted
- Notice the feelings you experience and accept that error is humane.
- Practice humility and Egoless Programming
- Try again with a smaller step
- As the day goes by, notice how your capacity for flawless work decreases!
Benefits:
- With time you’ll learn how much you can do without mistakes
- This teaches you to do extra small steps that cannot go wrong!
- This helps to understand when to call it a day and leave
- This avoids writing low-quality code when you are too tired
References:
Slow Self-Retros
Take the time to observe what happens inside us:
- Set a timer to ring every 5 minutes
- Every time it rings, take a short pause and fill out this log individually:
| ROTI | Did | Learnt | Puzzles | Feelings | Need | Decision |
|---|---|---|---|---|---|---|
| … |
Benefits:
- Helps us to spot our non-constructive reactions to events like:
- “I don’t know how to do that!”
- “Damn, I was sure this test would pass! I’ve got no idea why it’s failing!”
- “How stupid I am!”
- “I don’t understand anything about this code!”
- Develops our knowledge of inner feelings and needs.
- Provides plenty of data for continuous improvement and retrospectives of all kinds.
References:
Slow Communication
For the sake of organization, I put only Slow Code Reviews in the category of slow communication. Yet, Slow Navigating could also go in this section.
Slow Code Reviews
Take the time to offer non-violent feedback to your colleagues:
- When writing reviews
- When voicing feedback in the mob
- Follow the Non-Violent Communication pattern:
- List the facts
- Share your feelings
- Share what needs you have
- Suggest a new way of doing things that meets everyone’s needs
Benefits:
- It prevents conflicts from building up for the wrong reasons
- It improves teamwork, psychological safety, but also the efficiency of reviews
- It leaves the door open for more creative solutions
- It builds our feelings and needs fluency and self-awareness
- It is a way to start learning Non-Violent Communication
References:
- Nonviolent Code Review
- Five Strategies For removing Violence From Code Reviews
- Non-Violent Communication In Code Reviews: Receiving Comments
- Resolving Code Review Conflict In A Hippie-Dippie Way
Slow Mobbing
Finally, here are two practices specifically suited to mobbing or pair programming.
Slow Driving
Take the time to be aware of your feelings and thoughts when driving:
- Accept, or even better, relax into being navigated!
- Stay focused on typing and do what you are asked to do
- Focus on the touch of the keyboard and what displays on the screen
- Don’t judge what you are asked to do
- Breath while compiling or running tests
Benefits:
- This driving ‘pause’ makes the mobbing more sustainable
- It helps to take a step back:
- Let your creative mind work in the background
- Come back to navigation with a new perspective
References:
-
[Mindfulness For Programmers. 3 simple exercises to be more present… by Julia Di Russo Towards Data Science](https://towardsdatascience.com/mindfulness-for-programmers-da6f92147b8f)
Slow Navigating
Take the time to practice egoless programming while navigating in the mob:
- When other mobsters seem to be struggling with something you’ve figured out:
- Observe any criticism or judgment that you may feel.
- Instead, try to be patient and compassionate.
- When you struggle to understand or solve something:
- Observe any self-criticism or self-judgment that you may notice
- Instead, try to accept these feelings and let them go.
- When other mobsters come up with different solutions than you: - Strive towards egoless programming and humility by welcoming their solution
Here is a variant:
- Take a step back in the mob:
- Strive to remain a neutral observer of the mob
- Keep a log of what is happening and the mood of the mob. (a bit like Slow Self-Retro)
Benefits:
- A compassionate behavior builds psychological safety, improving decision-making and team performance.
- A “mob log” can be handy for continuous improvement and retrospectives.
References:
- Extreme Programming Creator Kent Beck: Tech Has a Compassion Deficit
- The 10 commandments of Egoless Programming
Try the workshop!
Here are the slides for the workshop I gave at XPDays Benelux.
My first recommendation is to try the workshop yourself. My first try at “slow self-retro” was mind-blowing. I was dumb-struck to see the emotional roller coaster a simple kata would get me through! If you have close peers to try it with, slow mobbing will teach you even more!
Also, next time you face a team with no time for coaching, don’t try to force it into their calendar. Has the team got “down time” in its calendar: Scrum slack-time, SAFe Innovation & planning? (Or August in France 😉?) Suggest volunteers try this 2 hours workshop during this downtime:
- “Slow Driving” and “Slow TODO List” make work more sustainable and productive from day 1!
- The other techniques need more time to install (that might be a topic for a follow-up post)
- All practices will get them to explore an ignored facet of software development
Whatever you try, I would love to read your feedback!
Here are other articles that might interest you:
- Technical coaching can be exhausting at times. Here are “3 Questions To Let-Go Technical Agile Coaching Measures” and “5 technical agile coaching tips to fight exhaustion from laggards.”
- Here is another post containing other experimental technical coaching practices: “How the pandemic made us discover better ways of coaching.”
- 100% pairing can be difficult for some people. Here is “How to use Mob Programming at the rescue of Pair Programming burnout.”
- Slow TODO List is a direct use of the “TODO list or Mind Map for programming,” the only difference being a shift of intent from productivity to calm.
- “How to help a team to find their preferred mob programming rules?” presents how to use a mobbing code retreat to experiment with new rules for mobbing. This could be the perfect occasion to try slow mobbing!
Leave a comment