“A picture is worth a thousand words”. In many cases that hundred year old adage proves to be true.
In fact, I thought of that saying the other night when I was lying on the sofa in my living room.
I was looking up at the ceiling when I remembered the time I’d hired an electrician to rewire and replace all the lights in the flat.
One end of the living room serves as a dining room so, when replacing the lights in the room, I requested that the lights work so that flipping one switch would light up one half of the room, and then flipping the other switch would light up the other half.
How I wanted the lights and switches to be set up
I remember discussing this requirement with the electrician at the time, and I felt fully confident that we both had the same understanding of how I wanted the lights to work. However, when the electrician showed me the completed work, it became apparent that we didn’t have the same understanding as I thought we had. He had configured the lights and switches to light up two halves of the room, but he had split the room along the opposite axis.
How the electrician set up the lights and switches
As I was replaying the comical situation in my head, I thought how I wish I had drawn out a quick sketch to base our discussions on. If I had done that, then we would have been less likely to have had the misunderstanding.
It’s a common pattern that I see occur in software delivery teams, where even after what feels like endless discussions during story grooming sessions and planning (usually in front of Jira or a similar electronic tool), we still end up with misunderstandings around requirements.
If we are lucky, we are working with product owners on a daily basis and these misunderstandings can be worked through as part of development. However, we know this might not always be possible, and we also know that effective communication is inherently difficult (Individuals and Interactions over Processes and Tools), so why not use anything that would aid us in these conversations such as sketches or even lo-fi prototypes?
Teams that I am currently working with sketch everything out as a group just prior to implementation (other than the most trivial requirements) to ensure that everyone does have the same understanding. It seems to work really well: everyone generally does seem to have the same understanding and it means that grooming and planning are more interesting and less focussed on monotonously discussing some words on a screen.