W5H3-A model for communication in software development

I first gave a talk about my model for communication at DEWT6 (Dutch Exploratory Workshop on Testing) in January 2016.

At the core is a very extensive mindmap which is intended to model all the different aspects of communication before it takes place in the context of software development, especially software testing. My examples are geared towards this area but it works for completely different areas as well.

The idea is for an upcoming conversation, meeting or other communication event to go through this model in advance and take notes (if needed) in order to improve communication.

People at DEWT suggested that they can see it being useful for retrospectives as well – how you use it is up to you. Adding to it may feel right, removing some parts to make it easier to work with – work with the mindmap that is right for you. After the talk Zeger van Heese (@testsidestory), suggested adding “feedback” to the mindmap and how to ensure that what was said wasn’t understood in a different way. That makes a lot of sense to me so that’s in now, thanks for the contribution!

W5H3 mindmap

Click on the map or here to go the Biggerplate site if you’d like to download the map. Without it understanding the model will not be easy if not impossible.

It may be useful to start at the top right (Who) and then walk your way through it in clockwise direction. That way it’s easy to figure out Who one wants to communicate with, What should be communicated and so on.

Adverse factors is an area that lists a couple of problems why communication may fail and what to look out for, something to check your approach against once it’s about finished.

Here’s an example how you may want to use it:

“I want to talk to a Software Tester about the testing they’ve just done.”

  • Who is clear in this example, the tester.
  • What I want to talk about needs to be clearer in my head. It could be test coverage, approach they took, potential problems discovered, …
  • Why do I want to talk to them about it? Do I feel unsure that they have the skills to cover all aspects? Maybe it’s an area that I don’t know well and want to learn something about. Maybe there are several aspects as to why I want to have this discussion. To me this is one of the most important but often overlooked areas. The 5 Whys technique may be used here as well to get to root reason for communication.
  • When do we have a discussion, right now, in an hours time? Maybe schedule in a weekly or daily meeting?
  • Where do we want to have this conversation? In my office? Do I sit with the Tester in their open space office? Do we go to a meeting room or even go offsite? How does the where impact communication in this case?
  • How much do we communicate? If the Tester is new in the team there may be a need to communicate a lot more tacit knowledge compared to long time employees in the company. Do I want to get a high level overview or go into specific details?
  • How many people are present for this conversation? Is it a 1:1? Would it make sense to ask other testers to join us and have a group discussion?
  • How is the biggest part and needs a lot of attention. The how is where all the information from the previous questions is distilled into an approach. The participant(s) may be insecure but experienced, boisterous but newbies, feel more at ease in a structured environment or not, some people can be criticised easily but feel not taken seriously if that doesn’t happen and so on. Different tools can be applied and combined in order to reach the goal of this conversation. Feedback from the communication partner determines how the approach may need to be changed during communication.

Check the adverse factors node for anything that may have a negative impact that hasn’t been covered by the rest of the model.

The “NOT” heuristic

I used the NOT heuristic to both get more ideas and to validate the thoughts that I have.

I’d ask not only Who do I want to communicate with, but also who NOT? Why do I want to communicate with someon or why NOT? This way it’s less likely that certain aspects are missed and it’s easy and fast to do.


Transformational Leadership part II

In the first part of the Transformational Leadership blog I described the theory. This second part is an experience report with a couple of examples.

I’ll start with the pre-requisites linking back to the first part; Willingness to experiment, Trust, Patience, Passion

When I started a new job I had enough passion – of course I was eager to do my best in the new role. In the beginning I didn’t have to worry about Senior Managers being impatient, the new guy bonus helped there. That left trust and the willingness to experiment. The latter was OK with senior management but for the team to experiment I had to gain their trust first.

The situation was such that the existing team hadn’t had a Test Manager for over a year and they were somewhat disillusioned but hopeful that the new guy would stand in for their interests. They were experienced and knew what they were doing with a lot of domain knowledge that was completely new to me.

So I sat down with them as a group and individually and asked them to tell me what went well and what didn’t (the latter list was longer…). Problems ranged from test environments going down several times a day, no commonly used bug tracking system and builds being thrown over the wall on the group side. On the individual side some haven’t had payrises in years, wanted to learn about other parts of the system but were stuck and felt that their contribution wasn’t valued.

So first I just listened to their problems. I also sat down individually with each tester to watch them test. That way I could learn the domain and also see how they approach testing their particular area of the system.

Within a short time we sent out some  guidelines how to use the bug tracking system (explaining the why) and introduced a template (the how) so that all necessary information was included for the developers. I had a chat with the development manager about the quality of the builds and what kind of problems to find in the test environments were acceptable and which were not – basically test entry criteria. He in turn sat down with his team and told them that the throwing over the wall times were over and that I would reject builds if they weren’t up to scratch. He set up monitors naming and shaming the developers who broke builds for everyone in the big office to see which improved build quality remarkably.

That all didn’t really take very long. What was probably even more important than getting more stable builds is that I gained the trust from the test team. I trusted them to continue testing the builds with their experience and domain knowledge while I continued to make them look better and remove problems in their way.

Another approach was that I mapped the test environments servers and applications, compared to our production environment and went to my boss to ask for money to get more servers plus time to get it all installed and configured. This also helped to show that I was indeed listening to their problems and doing something about it.

Since a trust relationshiop was built at that point I sat down with each tester individually and asked about what they thought would be needed next to bring the team forward and how they could help. Everyone had their own drivers and motivation so I introduced coaching for some and mentoring sessions for others covering the Individual part of the Tranformational Manager aspects. In team meetings I involved everyone in decision making, for example which new bug tracking tool we should go for and which ALM (We went with Fogbugz and TestRail).It helped the team spirit that people felt that they could bring in their own ideas and also get them implemented.

By that time we got more people in (one problem was simply not enough people on the ground) and everyone helped out when the going got tough. When one tester spent a lot of time on the private mobile (which was unusual) I asked if there was trouble. He replied that his kids and also his wife was sick at home and he was worried. I sent him home as his mind was clearly elsewhere. The work still needed done but others in the team jumped in and covered his most important work so he could go home. That was great to see and a sign that the environment and team identity aspects were progressing nicely. With an environment working and team identity like that I rarely needed to ask for overtime. More often than not people told me that they’d stay longer or come in on the weekend to get something done in time because they knew how important it was.  Knowing that if they had an emergency they’d get help made sure there was a drive to give something back.

What also helped is that we held a couple of meeting not in the official meeting rooms but in a cafe/bar down the street which was much more relaxing and actually more productive as well. Creating a stress-free environment got the whole team more productive as no time was wasted for people to cover their backs.

On a different note we had a three strikes rule – make a mistake once, no worries, we learn from it but please share it. Make it twice and we have a chat how to prevent it in the future and what we missed when we first thought we learned the lesson. Making the same mistake three times was a case of wtf, where’s your head, are you overwhelmed, do you have personal problems, what’s wrong? Note that I never had to go to part three.

SIDE NOTE: I wish I knew of Jurgen Appelo’s Delegation Levels from his Management 3.0 Workout book, that would have helped enormously.

Pairing with developers was another big step which worked really well on several levels. Testers got an early view of the implemented new features. Developers had to actually get their code to a stage where they could demonstrate it (which worked well after a first few embarassing fails). And they learned what was important for each other increasing mutual respect. The value of this cannot be overstated, a lot of communication problems, delays, misunderstandings and rework disappeared due to pairing.

These examples conclude the transformational leadership post. If you have examples of yourself or want to comment where you see things differently please share.