There is no greater threat to an idea than it alienating the very people it purports to help. Technicians can be deeply reflective, serious people, so forcing them to take part in trivial team building exercises can do more harm than good.
Being an occasional extrovert, I had a favourite game I used at the start of retrospectives. “If you were an animal in the jungle of your organisation, which animal would you be and why?” I think I learnt it from the fabulous Mike Lowery and have used it extensively ever since; until recently when I was given cause to rethink my approach.
The game’s purpose was three fold:
But after one rather excellent retrospective one of the senior programmers came up to me and said, “Please don’t ask me to be an animal again.” I looked at him open mouthed.
“It has no dignity.”
The conversation ended right there. Not another word was exchanged.
But it got me thinking. I realised that I had to enhance my facilitation skills to include everybody, not just those willing to risk a gentle ribbing by choosing a peculiar animal.
I now use a variety of different techniques to open retrospectives, and yes, I still sometimes use the “Animal Game,” when the situation warrants it. But I have found a wealth of information and great ideas in the book, Training from the back of the room, by Sharon L. Bowan. Sometimes collaboration requires deep thinkers to open up, and I don’t think this can be avoided completely).
Plenty of technicians are introverted, thoughtful and serious. When you run your team-building games, make certain you have the mandate to do so, and be sure that you are helping people to come forward, not filling them with dread.
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.
By William Knight