Fear Free Development
Scrum usergroup Karlsruhe»
Today I joined the online zoom event of the Scrum User Group Karlsruhe.
It started at 9 am CET in the morning, because we listened to Emad Al Hajjeh from Sydney where it was 5 pm AEST.
It was the first (online) meetup for me after quite a while. It started well for me having a very short chat with Dr. Jürgen Hoffmann (@doc_mentos), the groups organizer, before more people joined. He’s doing agile consulting, is a well known member of the scrum community and author of “Agile Unternehmen” (german for Agile companies), a well recepted book about agile transformation.
I used to regularaly visit tech and agile meetups before pandemic, such as the two agile/scrum related groups from Freiburg. One of them is the Scrum User Group Freiburg, where I listened @doc_mentos some time before, the other is the ‘Agile Black Forest meetup’, organized by Christian Schneider (@herbivore). The latter used a lean coffee format instead of having a speaker giving a prepared talk. So that one really lives from human interaction and was AFAIK not tranformed into an online event. I really miss those meetups, but I think it’s a good idea to join online events and see where this leads you.
Impact of Fear»
Back to todays event. Emad, the speaker, currently experiencing Australien winter and a Corona lockdown in Sydney, started with a definition of Fear:
Psychologists say that “when we are in a state of fear, we compromise our ability to process thoughts and events rationally. Our brain wants to protect us by sending us in a direction away from the pain point.”
This sentence also explains the reason why we could walk across a wooden bar between two beer crates but would fail to walk accross the same bar when it would connect two skyscraper roofs. Then it would be much more likely to step next the bar with fatal consequences. All because your brain wants to ‘safe’ you from danger.
So if we actually want to achieve our goal, but at the same time we are afraid of it, we get easily distracted and do anything rather than pursue the goal. Suddenly it seems much easier to drift away and achieve other goals instead. As a result, we become unproductive and inefficient.
And this can happen quite often, even me right now. If I fear writing this blogpost could take me forever as I am not used to write blog posts, it could be was much easier to think about styling the tooltips. ;)
I repeatedly noticed that some topics at Scrum events are what is called “old wine in new bottles”. That should not devalue Emad’s lecture, because he transferred the topic very well to software development. In his professional practice within different teams he noticed what kind of problems occurred and what and how to possibly solve them.
Emad stated among other things that Fear from failure can lead developers
- to avoid taking initiative and solving problems
- to be reluctant to try new things or getting involved in a challenging problem
- to hold himself back from success being self limiting or even sabotaging himself
Key Practices - Engineering»
And what developers led there were ‘developer nightmares’, e.g. complex and not documented code, code from others, when a bugfix leads to even more bugs, lack of related business cases, unknown or new design patterns, new technologies or spaghetti code, to name a few. Eventually developers are afraid of changing code at all. They will spend their time on thinking how to avoid more issues but not on the current task itself. This leads to long time to release, small features become a big long projects, code becomes complex and challenging to maintain.
To make a long story short, along with coaching the developers in agile methods Emad suggests several key practices to overcome these problems. Developers should
- test and own test automation, and even make unit tests mandatory
- own the pipeline and adopt true CI/CD so they have always/daily a deliverable product
- adopt trunk based development
- improve continously their code
- stay away from nightly builds to achieve fast feedback
- focus on writing code and design solutions but away from other roles (Scrum Master or Business Analyst)
- while Business Analysts should write really good user stories but not solutions
He also encourages developers to apply XP techniques, but I won’t replicate those here.
The Forgotten Agile Principle»
Emad recalled the following agile principle as the not so much talked about pillar for sustaining Agile delivery without burning the team.
(9) Continuous attention to technical excellence and good design enhances agility.
In general I liked Emads talk and his conclusions, although his view was mainly focused on the developer role and engineering side of the story, starting with the fears from developers like e.g. making technical changes to a complex codebase.
So he gives attention to these things to overcome ‘fear of technical fault and bad design’. Overall this is very consistent to and already part of the abstract of his talk.
“In this presentation, we will go through what could trigger the “fear” feeling in developers and what can be done to reduce it. Also, we will talk about how completing an Agile process with a software engineering process like XP (eXtreme Programming) will help the team sustain high-frequency delivery and release with joy.”
Different fears»
My expectation when talking about fears would have been a much broader view on different fears a developer or the team of developers could have which directly influences teams motivation. While ‘deadlines’ or time pressure have been mentioned in his talk, I miss other non-technical reasons, which might be related to the organization or customer relation.
- a company’s or department’s management style
- doing bad estimates and become measured by them
- not getting the support needed and being a lone fighter
- reacting to the absence of external dependencies
- relations between people or dealing with absences of people
- justifying for less productive times
- or to not meet stakeholder expectations
This view is influenced by my work life, as I was and still am working for a software agency, service provider or a subcontractor to name it. So I would highlight other agile principles as well, the one about the environment as well as the one about reflection and adjustment.
(5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
(12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
These are of course well known building blocks of scrum. A good Scrum Master would be a perfect facilitator of a secure environment, where developers don’t have to be afraid. One of these environments is the Retrospective where the team shares and fights their fears together. They calm down for a moment to ‘inspect and adapt’.
In the Q&A part of the event, there was the question what and how to measure fear and their impact. I can’t recall everything, but velocity aside, you’ll probably notice in a distorted communication, avoidance of estimations or decisions, justification or blaming and even no communication at all.
Conclusion: Be aware of fear and their impact and work together on your safety net, technical and human.