“Feeling” software development, drawing a house

I recently spoke to an audience of project managers, campaign managers and statisticians in the market research and marketing world: people very distant from software development, but somehow very interested about what the company I work for do.

At ZappiStore, we automate market research insights. What we do is really appealing, but it is a real novelty in an industry where traditional market research companies are still the big players.

I had to explain what “agility” means in the IT sector and how it relates to them. Having people “feel” the difficulties of software development turned out to be a challenge.

Inspired by the work of Tom Reynolds[1], I created a short workshop.

My point to prove was quite different: instead of focusing of acceptance criteria, I focused on the difficulties of the discovery phase and how much can get lost in communication.

 

The original Reynolds’s House. Print your house on thick paper, so people can’t see through it.

The activity that I am about to describe is a metaphor for a customer asking for an end result (knowing nothing about software and its lifecycle) and explaining it to our software development department.

 

I wanted people to understand:

  • how much can easily get lost or misunderstood in the communication channel
  • show how natural it is to start “gold plating” and adding unnecessary features
  • the need for re-learning what was done in the past

 

The exercise goes as follows:

  1. I split the audience, creating couples.
  2. I gave a sketch of a house to one person in each couple (A) and a “magic pen” and paper to the other person (B)
  3. I asked the person with the house (A) to describe it in 3 minutes, while the other (B) was tasked with capturing all the information in a written format
  4. The second stage of the exercise is for person B to recreate the original drawing using the captured information (about 3 minutes)

 

What’s a magic pen?[2]

Well, it writes invisible ink. The ink becomes visible when a special light is pointed at it.

Why?

As you draw an invisible house, you start forgetting where you drew, so you require the special light to check where lines begin and end, in order to continue your drawing.

At this point (you probably guessed it) is the re-learning experience that every developer goes through on a daily basis when extending functionalities or fixing bugs.

We had about two dozen couples in the room and 10 minutes for the exercise.  In retrospect, I would suggest trying this exercise with no more than that.

After the exercise, I took another 15-20 minutes for debriefing.

We had an entertaining discussion, as we went through the differences in interpretations, drawing skills, and how the drawings evolved in different ways given the various backgrounds of the drawers.

The invisible drawing, and a magic pen The drawing, when using the special light

The invisible drawing, and a magic pen

The drawing, when using the special light

As expected, no house was perfect.

The reason for divergent features in the end results are mostly to be found in the subjective understanding of each individual.

A square box on the side of the house was sometimes described as a garage, so it became a garage.

  • Windows that were originally drawn as squares, got curtains (even though nobody described them).
  • There was a sun and many birds when none of these were present in the original.
  • There were missing pathways to the front door.
  • Sometimes the fence before the door had no entrance.

 

I asked how people felt having to deal with an invisible drawing, and I guided them into understanding how it relates to software development.

The most experienced in the room were already well aware of how easy is to miss details and misinterpret them during collection of requirements.

I explained how easy it is to end up wasting a lot of time on gold plating an existing working functionality, while that time could have been spent developing new features that would bring new revenues. Or making sure that what was drawn was actually correct.

We also discussed how any additional non requested feature translates to additional risk and increased maintenance (in both the invisible drawing and software development there are ‘more lines’ to deal with).

It was a good starting point for having a discussion and it was a good experience for me and entertaining for the audience.

Would you suggest any improvement or change?

I hope you will enjoy giving this activity a try. I will be waiting for your feedback!

[1] https://www.scrumalliance.org/community/articles/2014/may/acceptance-criteria-demonstrate-them-by-drawing-a

[2] http://www.amazon.co.uk/dp/B00M95RP1Q

 

 

Driving the change, creating and growing a sustainable and energetic work environment are what motivates me. I have over 6 years of experience in the field, including roles as Professional Services Operator, Software Engineer, Scrum Master and Agile Coach, from startup to corporate environments. I actively challenge teams and management to see things from different perspectives, identifying biased beliefs and allowing for experimentation on all areas of the Software Development Life Cycle.
Tags: