By Nick Butler
Tags: Agile , Development
Boost is an Agile company. We use Agile practices for all our client projects. About a year back our Culture Lead, Gavin, decided to try fortnightly developer retrospectives: all the Boost developers come together to look at what’s working well and what can be improved. We call it the Dev Retro. Find out how developer retrospectives affected team happiness at Boost and why they work.
Developers are generally not known to be great communicators (I don’t speak for all of us), so it’s hard to measure how happy developers are at work. High-tech companies like Google and Facebook are known for their fun work environments, toys, food during working hours and so on. This seems to suggest that most of the development companies agree with the idea that “happy software developers perform better than unhappy ones“.
But does this approach fix everything? The answer is no. That’s because it assumes that providing perks keeps developers happy, so a fun workplace is the fix for all team happiness issues.
Now let me summon my developer skills to explain this:
The above ruby code assumes that some issues may arise from the general team happiness of the company but we don’t know what exactly they are. So we are using a rescue clause to catch them and fix them by providing perks. However the above approach does not consider that different issues might be reducing team happiness, and that some of these issues might not respond to perks.
As I wrote this code in my Sublime editor, the magnificent editor caught an error on the third line. This error exactly shows the problem with providing perks to the team and assuming this is the fix for every issue that might arise.
The error says that the issue is not being used meaningfully anywhere in the code. This means the perks strategy does not consider what the issue is.
Now best practice to handle this issue in the above code is as shown below.
In this second approach we are catching specific issues around team happiness and providing specific fixes for them. When a new type of issue arises we analyse it and later on add new exception-handling to our code.
Developer retrospectives gave us the ability to find out what the specific things are that the dev team are unhappy with and propose goals to solve these.
We work with big and historical codebases. As time passes knowledge gets lost in the ether of Git commits and deployments. This leads to a situation where newer devs are unable to understand how things work and why some solutions were written the way they are.
A goal that came out of one of our retros was to identify areas in projects that need to be better understood. The whole team should discuss how this area works. As a result developers who have worked on it in the past can refresh their memory and help in the discussion. During this exercise we also draw a process flow of how the program works and record it for future reference. We have appropriately named this exercise “What The Flow” (WTF). This has now became a standard practice at Boost.
This comes back to one of the core ideas of Agile, Self-organising teams. Dev retros let developer teams become the decision-makers around their happiness at work. Dev retros also help continuous improvement for the dev team. They are cost efficient for the employer; the only thing that needs to be provided is one hour every fortnight for the dev retro, rather than spending money on perks that might not appeal to the whole team. We (devs) are happier, and the world is a little better than it used to be.
