Rachel M. Carmena

Discussions

Published: 2 January 2019
Last updated: 27 June 2019

This post has 2 different parts. Firstly, I talk about the power of the discussions. Secondly, I give an idea to have useful discussions.

However, maybe this post is talking about estimates and documentation ;)

The power of discussions

I’ve participated in meetings to estimate tasks following Planning Poker. Sometimes, using the original cards. Other times, using other type of cards (for example, T-Shirt sizes).

I hardly saw an accurate estimate.

However, I had very interesting discussions during those meetings:

  • To understand the needs or the problem
  • To divide, order or change the tasks

I remember this situation when I was 5-6 years old.

At night:

Me: Mum, please, water!

My mother: Here you are.

Another day:

Me: Mum, please, water!

[a few minutes later]

My mother: Here you are, my child, my child, your water.

Me: Oh, mum, I fell asleep…

Another day:

Me: Mum! Please, I cannot fall asleep. Can we play a game? I ask you for water, but you don’t come. So, I will fall asleep as it happened the other day.

My mother: What?

So, can we play a game? Can you ask us for an estimate? But you don’t really want that estimate. You only want us to have a discussion to get valuable information.

An idea to have useful discussions

A discussion can be a mess when each person has a different thing in mind. We cannot read the mind, so it’s very useful to draw the ideas on a paper or a board.

I don’t know how to draw my idea

In order to face that situation, I find it very useful to know some notation or language to get graphical representations. I like to use BPMN or UML depending on the goal.

A few days ago, Ivar Jacobson, one of the creators of UML, wrote an article about it: Rumors of the death of UML are all false. I love these sentences:

No doubt that UML contains many very useful diagrams when discussing software architecture.

Sequence Diagrams are one of my favourites.

(…) if UML is used in a smart way it really helps the teams to understand where they are heading.

On the other hand, Simon Brown thought about having different zoom levels to explain software architecture according to the target.

He created the C4 model based on 4 zoom levels (or levels of abstraction):

  1. Context in terms of the people who use it and the other software systems it interacts with.
  2. Containers: applications, data stores, microservices, etc.
  3. Components for each container.
  4. Code for each component.

This model doesn’t prescribe any particular notation for representing each zoom level.

I like this reflection by Simon Brown when talking about documentation:

An unfortunate and unintended side effect of the Manifesto for Agile Software Development is that many teams have stopped or scaled back their diagramming and documentation efforts, including the use of UML.

Further reading