Simon Baker has written a superb post, capturing the elusive nature of empowerment.
He mentions “an environment that tolerates mistakes to cultivate learning”. For me, this is an essential part of innovation; of the Lean metaphor that suggests a Software Development team is more like a Product Development team (designing new cars) than a Production Line (churning out the same thing repeatedly).
In a Production Line, we try to minimise variance (think Jidoka and Continuous Integration and Deployment).
In a Product Development team, we try to maximise learning opportunities, which means experimenting (think risk, innovation and doing things no one’s done before).
“There is no such thing as a failed experiment, only experiments with unexpected outcomes.”
— Richard Buckminster Fuller
Are mistakes in Software Development really mistakes? Or just experiments from which we learn something new? And if they keep happening… what didn’t we learn?
I’ve been wanting to try out Edward de Bono’s Six Thinking Hats for a while now, and finally got the opportunity in a workshop last week.
I was working with a team who had a vague understanding of the roles we ought to be playing, and we wanted to clarify them. We only had a short time for the meeting, so we used the hats to help us. In an unstructured meeting, everyone will have a particular bias. Some people are very positive and look for the good in everything. Others are risk-averse. Others like to concentrate on the facts, or see the big picture. By focusing on each aspect of these in turn, we were able to give voice to everyone’s preferred bias.
As the facilitator, I took the blue hat – the big picture – and used it to introduce the agenda for the meeting, outline our objectives, and summarise what we’d learnt at each stage. Each stage was simply a brainstorm with post-it notes, which we stuck on different areas of the wall around the room.
The team started with the yellow hat, looking at the positive aspects of the problem – what our proposed solution would achieve, and what resources and people we had available or hoped to use to solve the problem.
Then we used the black hat to work out what risks might jeopardise our solution. I used the concept of a futurespective here, too, as a number of the participants confessed to having a positive bias. “It’s three years from now, and we failed. Why? What happened?”
The white hat – focused on facts – helped us look at what we knew about the problem and the solution, and what was still puzzling.
At each stage we spotted themes. I now took the blue hat again and repeated these briefly for everyone present.
We used the green hat creatively to work out what our roles should be, given the yellow, black and white hats.
As a result, we realised that up until the workshop, we had been very focused on technical detail, and not as much on the people-oriented aspects of the problem. I kept the red hat with its emotional focus in reserve in case anyone seemed unhappy, but everyone was smiling when they left, and my team-mates declared the workshop a success!
I borrowed the programme for the hats from Wikipedia, which has a great summary. We ran the meeting across virtual conferencing in three countries, using big, coloured pictures of hats to remind everyone of the focus, and to provide a visual anchor and memory aid. Dan mind-mapped the results; this also works very well with the pre-defined themes.
Next time I think real (or paper) hats may be in order…
I hate blame cultures. If you hate them too, then you don’t need me to tell you why. If you don’t, you probably haven’t worked in one yet.
At one client, they have a strong dislike for blame cultures. Unfortunately, most of the development team have worked in one at some point or another, and it’s hard to get out of certain habits.
“Ah, it’s all right,” one developer said, looking at a bug. “It’s not our fault.”
“I’ve been learning a bit of NLP,” I said, “and it suggests that the words we use can sometimes affect the way we think. I know that you’re not really thinking about blame when you use those words. Even so, can we avoid them? Could you maybe ask the question, Who’s the best person to fix this? instead of Whose fault is it?”
“All right. I’m still not the best person to fix this, though.”
“Well, who is?”
“I think George broke the build. I mean, George is the best person to fix it.” The developer called across, “George, can you look at the build a sec and see if you could fix it, please?”
“Oops!” said George. “I’m on it.”
So he fixed the build, and the team started working. A while later, one of the QAs called me over. “Liz, I’m looking at this bug… did your team cause it?”
I shook my head. “It looks like the database might be down.”
“Oh,” the QA said sadly. “I can’t blame you, then.”
I winced. “Why do you need to know whose fault it was?” I asked.
“So I know who to assign it to.”
So I explained about the new words we were trying to use instead of “blame” and “fault”.
“Oh!” she brightened up. “Well, are you able to help me fix it, then?”
“Maybe one of my team can help. Hold on!” So I asked around. “Who’s the best person to kick Mary’s database? It looks as if it’s fallen over.”
“I can do that!” Fred announced.
It occurred to me at that point that, if we were still asking, “Whose fault is this?” then Fred would be reluctant to help out, because it would insinuate that it was somehow his fault. By avoiding the words and asking, “Who’s the best person to fix this?” anyone can volunteer.
Suddenly, by providing an alternative to “fault” and “blame”, we’ve made it OK for people to volunteer to contribute. That can only be a good thing.
There’s a standard format for stand-ups that goes:
- What did you do yesterday?
- What are you going to do today?
As well as this, it helps to keep the focus on things that are interesting to the team.
Sometimes this can lead to stand-ups becoming little more than status meetings, or updates for a team leader’s benefit. So here’s something that I’ve been doing both for myself, and with teams, that seems to liven things up a bit.
- What did you learn yesterday?
- What do you hope to learn today?
Participants who’ve used this as well as or instead of the usual format have talked about contacts they’ve made in other teams, difficulties they’re having with particular technologies, puzzles they’re trying to solve, domain knowledge they’ve picked up or are looking for, etc.
A phrase frequently used in the Scrum teams I’ve been involved in – as well as a few of the XP teams – is “Pigs and Chickens”.
Googling the origin, I found out where it came from. Like many terms and practices in Agile Software Development, it’s surrounded by controversy.
I have come to love the phrase, mostly because it causes people who are unfamiliar with Agile and Scrum practices to ask, “What are pigs and chickens?”
When the Agile team members smile and happily explain the joke, the people asking the questions often remember that they have other questions they wanted to ask, too. Then they find out that most Agile teams are full of real human beings who love to talk about what they’re doing and share good practices. This in turn invites more conversation, which spreads the goodness.
That leads to requests like, “Liz, I’d love to see what the team are doing with <xyz>. Can I turn up at your meeting, please, just as a chicken?”
Anything which facilitates better communication – even by being an obscure hook that invites curiosity – has got to be good.
Comments