Hierarchy makes it difficult to be empowered
Quite a long time ago I’ve written a post about refactoring sessions I’ve introduced into one of my teams. They went very well for quite some time… and disappeared. How come when everyone said they liked refactoring? Fortunately the idea came back in a new form as inspectoring sessions which happen from time to time… but very regularly.
In this post I would like to write about three things
- Why refactoring sessions could have disappeared?
- What are inspectoring sessions?
- Why inspecting sessions can become part of our teamwork?
The key point that joins all three questions seems to be motivation. The refactoring sessions required the leader of the meeting to be prepared, to have a (rough) plan of refactoring, the goal, the refactoring steps. This entailed that the leader was (could be put) in front of 100s of questions and (maybe) better ideas.
Perfectionism kills motivation
This way conducting such a meeting required a lot of preparation and effort. Moreover meeting by meeting you had be prepared better and better. This way – as perfectionism kills – it seemed to be more and more difficult to decide to set up, prepare and conduct such a meeting.
It is called “trap of vicious perfectionism circle”. At some point you want to be so perfect that you are afraid even to try. It is called “trap of vicious perfectionism circle”. At some point you want to be so perfect that you are afraid even to try.
Our refactoring sessions has a strong expectation of success. Maybe it was just followed by the refactoring trainings I’ve conducted – as lots of people did really liked the refactorings we did. This was because these refactorings were (of course) prepared to succeed (like in such a training). In my opinion as a result of this (not written) assumption our refactoring sessions were organized more and more seldom.
New experiment followed by adjustments
I remember when one of the managers was encouraging his teams to experiment every Friday on new ideas with a strong emphasis on 50/50 chance of success. And he was 100% right! If your experiment cannot fail (or at least is expected to succeed) it is not an experiment! The only expectation for experiment should be to draw conclusions – from the failure or from the success!Fortunately one day one of my team members (thanks Jakub!) proposed a different approach. He suggested to set up “inspection of code” meeting. The formula – taken from his previous job – was going to be completely different. The meeting should have
- Code Reader – responsible for reading and explaining what the code does
- Conclusions Writer – responsible for writing down action points
- Code Author – answering questions if the reader cannot understand the code
- Moderator – taking care of the whole process of the meeting
The meeting went quite smoothly although it’s formula was slightly strict. As you know developers want to be flexible & agile, not strict. Therefore during next “code inspection” sessions we experimented more and more. The experiments led us to loosening up a little the rules and adding what we liked from the refactoring sessions – live code changes during the meeting and discussions.
This way we ended up with code inspectoring sessions (inspection + refactoring together) that
- Could be conducted by anyone
- Did not require the leader (reader) to be prepared
- Did not expect we will end up with much better code
- Were strongly expecting the attendees to be involved
- Where each opinion is considered and discussed
New motivational approach
The approach we found and use is “anti perfectionism circle of thinking”. We were expected to understand better given piece of code / functionality. To discuss it, and maybe to make it more readable if needed. We were (and are) striving for improvement (of our knowledge, of the code quality) but not for perfectionism. That’s it!
So the goal is continuous progress, not a perfectly set achievement / point.