Are you happy?
A few months ago I was a fill-in Scrum Master for an
established team. I relished the chance to work direct with a single team - the
opportunities are getting fewer with each year that passes.
The team was new to me, but they
were experienced. The Stand-up was smooth, finishing in less than 11 minutes. So
I did what I often do at the end of a meeting when there are a few minutes to
spare.
“Are you happy?” I
asked.
Silence.
Then someone said “That’s a bit of a
loaded question isn’t it?”
Sadly, this response did not surprise me. Teams aren’t
used to anybody asking about their happiness.
This is strange. Happy teams are generally more
successful and more productive than unhappy teams – so even if they have not an
altruistic or empathic bone in their body, leaders should care about their
team's happiness for the productivity advantages alone. So why do they never
ask?
“Actually, he means it”,
said the only team member who had ever worked with me before.
“I do,” I said. “Seriously, are you
guys happy doing this, or does this project suck?”
Stunned silence.
With 3 minutes left in my time-box for this meeting, I
concluded that this approach wasn’t going anywhere, so I decided to finish with
a monologue that might help them understand.
“OK,” I said, “We all know that projects have ups and
downs, but the fact is that you guys are going to do a better job if I can rig
things so that you are happy. If you wake up one morning and think ‘I don’t want
to go to work.’ I’d like to know, and I’d like to know why." Then I took a stab
in the dark - naming the most common reason that Development teams feel
unhappy... "If you start to feel like you are just a small cog in a machine that
is grinding you into the ground, and you feel like you have no control over the
machine… we need to change that. Think of it as being like inversion of control
– this team needs to control the machine. My job is to make sure you do
control the machine. We need to control everything in our environment that
impacts on your ability to do your job. We can’t afford to have you guys feel
frustrated for even 1 second. I know this won’t be easy or fast but you tell me
what needs to happen to control the machine, we will prioritise your list, plan
an approach, and then I’ll do my level best to get it happening for you.”
Disbelieving silence. Then a small
voice pointed out “But we are only small cogs in the machine. We don’t
control anything, we're just the dev team.”
So the next day we made a list, and I started work. I
felt like, having talked the talk, I'd better walk the walk. It felt like
jumping off a cliff and hoping that I could figure out how to build a parachute
on the way down.
The plan to
take control wasn’t simple - but it was quick to implement. We had to change the
concept of “team” to incorporate those directly upstream and downstream into our
new “extended virtual team”. The plan involved inviting them to our Scrum of
Scrums and aligning their vision statement with ours (pretty easy, since they
didn’t have a vision statement). It turned out that the managers in charge of
the other teams were strongly supportive of better communication and integration
and happy to have their team members "get updates" from my team.
Our "updates" quickly turned into
discussions and agreements about small workflow changes and process
improvements, most of which we just slipped into place immediately. We felt no
need to seek approval, so we didn't.
Did it work? Are they a happier team for this? Three
weeks later I left the team and went off to find my next problem. Their new
Scrum Master tells me that they raised my loss as an impediment. He also tells
me that they are holding him responsible for helping them control their
environment – something that he is quite happy about :-)
So don’t be afraid to ask your team “Are you
happy?” They might need some coaching on what such a "loaded question" means,
but once they understand you are serious be prepared for things to
change.....and be prepared to jump off that cliff.
No comments:
Post a Comment