alacrity in action
| Tags: , ,

The project was going well, at least as far as approach to analysis and development was concerned. We still haven’t agreed on a sensible approach to testing though. The issue has repeatedly been raised in retrospectives and has always sparked a heated debate as strong and, not always compatible, opinions were held. It was high time to tackle the challenge and agree on a sensible solution.

Drawing from Bill Jarrard

I have used Edward De Bono’s 6 Thinking Hats technique, based on De Bono’s book, before  but never directly applied in context of software development. Nevertheless, it seemed like a tool well worth trying, particularly given the emotions were running high.

The idea is based on the premise that our brain has different ways in which it operates and they can yield different outcomes. There are 6 hats, each with a different colour (white, red, black, yellow, green and blue) representing different thinking processes (facts & information, feelings & emotions, negative, positive & optimistic, creativity, the big picture). The team works through a problem by successively and explicitly applying different hats in their thinking. Sometimes real colourful hats are worn but usually just a motion of “selecting a colour” is sufficient. Depending on the problem at hand, its structure and required focus, the hats are applied in specific order creating a program (such as generating ideas, identifying solutions, process improvements, solving problems). For example, the following sequence of colours: Blue, White, Green, Yellow, Black, Red may be good for choosing between alternatives.

In this particular case we were hoping to improve our process with regards to testing so the following sequence seemed appropriate: Red, White, Yellow, Black, Green, Red; In each “round” people were writing their thoughts on sticky notes and we then assembled and reviewed them together. We have previously prepared a list of different types of testing we thought we were doing:

  • unit testing
  • integration testing
  • UAT testing
  • Web UI testing
  • pre-production testing
  • cross-browser sanity testing
  • system testing
  • exploratory testing

You might say this classification is not clear and perhaps overlapping. I agree but it didn’t matter as in this particular case these were de-facto different activities and understood as such by the team (although what each of them was exactly supposed to achieve was not that clear). The goal was to establish a shared understanding of what they meant and if the structure needed changing.

We started with a swoop of people’s emotions (a red hat, a rather quick one) to clear the air. Then, we went on to gather information and facts (white hat), collected thoughts on positive and optimistic aspects (yellow hat) and then looked at things critically (black hat). Finally we generated some new ideas and insights (green hat) and applied the red hat again to gauge the emotions. The session was fairly short and fast paced so we were all somewhat drained at the end but people were clearly happier having gone through the exercise.

Here is a mind-map summary of the session with many of the thoughts captured. It’s not as relevant though as the outcome the session had for the team. We have finally felt we were on the same page with most concepts; we have surfaced many good ideas and advantages but also fears, worries and problems. Thinking about only one aspect at a time we were able to break out of the vicious circle fuelled by emotions and different implicit mindsets.

In the next retrospective we were able to put together a plan of concrete actions to improve the situation that got buy-in from the whole team. Subsequent iterations have seen many of these actions implemented and as the result, the team was happier and we were able to improve quality of our system.

The 6 thinking hats allowed us to move forward in a way that other retrospective techniques before couldn’t.

| Tags: , , ,

I like when that happens. I grabbed a “random” book in the office, flicked through and it turned out to be a real gem. “The Trusted Advisor” by Tom Peters, David Maister, Charles Green and Robert Galford is unsurprisingly all about trusts. It talks about the role and importance of creating and sustaining trust for professional consultancy services. You can use it as a guide for building and evolving trust. It describes what it looks like when you experience a trust relationship and gives good reasons why trust is more important that technical excellence.

I really liked this book primarily because I attribute similar importance to trust. I also think it is still greatly underrated in both management and in IT industry but it is changing. Agile manifesto as well as XP both emphasize that software development is primarily about interaction between people (at all different levels) and about technical practices second. One of the principles behind Agile Manifesto explicitly refers to it: Give them the environment and support they need, and trust them to get the job done.

Refer to my mindmap as a guide through the book or a reminded of some of the key themes. Good, useful and relevant read. Recommended.

Give them the environment and support they need,
and trust them to get the job done.