Good technical skills not only help you take pride in your work and produce error free software, they can also boost the team’s happiness. Let’s take a look at just one aspect: CI or Continuous Integration.
It’s funny how things work out. Last week I posted a blog on how agile philosophies can promote a team’s well-being because they align so well with the things that make most people happy. And then over the weekend I saw that Dave Fecak writing for DZone (a famous Developer EZine) had conducted a survey on developer happiness.
There’s a mine of good information in Dave’s article and I recommend you read it. But since CI (Continuous Integration) has become a bedrock of technical practice – and hence a first level agile technique – I asked for a few of the source statistics and kindly received a reply.
Five hundred and four DZone readers** responded to the Continuous Integration question and of those 280 did CI, and 224 didn’t.
Of the 280 that did, 67 were happy, 150 were average happiness, and 63 were unhappy.
But, of the 224 that didn't do CI, 23 were happy, 111 average, and 90 unhappy.
“So the number of unhappy [people] in the non-CI shop were almost 4 times the amount of happy,” Dave Fecak says. “Thus, my theory that CI doesn't make developers happy, but the absence of CI might make them unhappy.”
Why might this be so? Using the SCARF model of Status, Certainty, Autonomy, Relatedness and Fairness, here are a few potential reasons:
I don’t think Dave Fecak’s results are an accident. Good technical practice is essential for mastery of software delivery and CI is a critical technique. Done well it improves quality, efficiency and communication which enable teams to work better, collaborate better and resolve issues faster.
Of course CI keeps you happy.
**The audience for this survey was DZone readers mostly or people that read about it on Twitter. “It's not a perfect study by any means, but I thought the results were interesting,” says Dave.
The latest research into what makes people happy intersects neatly with agile philosophies and good collaborative practices. If you want the best from your teams and you want them to be content, you’d better go agile.
Grumpy, uncommunicative work places are a scourge in digital and IT departments. I’ve worked in offices where retrieving a ‘good morning’ was cause for celebration and where a chat round the water cooler was frowned upon as disturbing the work ethic. But common as these things are, they do not help the well-being of staff, do not promote happiness and cause distress among the very people that are supposed to be making a difference to the organisation.
We all know that digital technicians and IT people are fabulously well paid. This is important for recognition but it turns out to be far from the most important factor for predicting happiness.
In David Rock’s excellent book How The Brain Works, he sets out five parameters for mental well-being in work situations:
Happy agile workers
Agile teams, and Scrum teams in particular, are encouraged to relate to each other, do not blame but look for solutions, and follow a strong vision. Team ceremonies build trust, continuous improvement is highlighted through regular retrospectives, and the commander’s intent, or sprint goal, gives certainty. A well performing team is in charge of how it builds solutions and the work it chooses to do (i.e. it is autonomous).
Agile promotes communication, vision, excellence and well-being through its rigorous processes, and attention to transparency. It turns out these are the very things that make most people happy.
And we all know that happy people are productive people.