The need for agile craftsmanship (Pt 3 / 4)

separator
agile craftsmanship header

 

Episode 3: The Melvin attitude

barbarian_chart_roundT

First Melvin attitude : The others are hell – Increase the Barbarian factor of your meetings

The employees of the retail company (of the above-mentioned example)  had a profound Melvin attitude. One of them stood with his finger against my chest . He raged against me in French and addressed me as "Vous". That was not intended as a courtesy form, but as an indication of my tribe: the IT-people .
Everything I said was stigmatized as merely IT-talk.

That is the first characteristic of Melvin behavior: others exist as a group and they are a bad group ! Or as the philosopher Jean-Paul Sartre wrote : L'enfer c'est les autres . The others are hell.

The problem of group isolation has to be tackled, because it kills any reasonable conversation.
I advocate a solution of a daily or weekly meeting with a very high barbarian factor . With barbarians I mean people belonging to the "other group". For IT this is "the business". For testers these are "the developers", and so on.

Many agile meetings are held within their own group/silo. This way the prejudices against the others are never exposed. My advice is to organise meetings where people push their finger against the chest of the others.
In every meeting there should be at least one barbarian!

In the aforementioned retail company , this in itself has already resulted in a reduction of the lead time to 1.5 months. This is not surprising. It is very difficult to send the other one an nasty e-mail if you meet him every day. And it's hard to ignore a question from the other if you're in the same meeting every day. In addition, we must not forget that 85% of lead time is waiting time[1]. So even if the relationships are more friendly, a daily meeting with all involved parties will reduce lead time.

[1] The lean approach identifies 7 types of waste of which waiting time is an important one. Analysis has shown that the total lead time of any process includes maximum 15% processing time. This means that in the process the goods are waiting for 85% of the time. Therefore we should work on reducing waiting time, because this  has the largest impact on overall lead time.

Second Melvin attitude : The other is an availability

But with just a daily meeting of barbarians you don't build cross-functional teams yet.
It may reduce the lead time, however real collaboration requires more.
In a cross-functional team the participants deliver greater results than they would be able on their own.

A cross-functional team is a whole that is larger than the sum of the parts. Putting Melvins in the same meeting doesn’t mean they will work with each other.

availabilities_chart_roundT

For example you will see that developers don’t collaborate with testers even if they have to deliver the same user story in one sprint. Another example is that people come to meetings, but don’t participate. They spend time checking their e-mails.

Last example : I have been in companies where people send emails to colleagues sitting next to them.

Why is this? Why do we refuse to work with the other ?

The philosopher Martin Heidegger  called this a problem of our time. He claimed that the reason for this attitude is that modern man considers everything and everyone around him as an availability [2].
He sees all things and people around him as something that is there for him to use.
After all, why wouldn’t he? Everything is available and has a button. Even the air and temperature around us has a button. We call it air-conditioning.
Everything is just there; buttonized and usable. So why wouldn’t the colleague just also be an availability.
I don’t communicate with my car, my pc or my coffee machine. So it is only logical that I treat the other as a thing with a button. Therefore I send it a mail, hoping it responds properly. Even if it sits next to me.

Agility requires a collaboration that is at odds with the world as we know it.
How do we solve this?

[2] See the text of Martin Heidegger, Concerning technology. In this text availability is referred to as Standing reserve, which is a translation of the German word Bestand. It seemed to me that treating the other like an availability is more obvious than treating somebody as a Standing reserve.

Provocative penguin math 

I referred already to a strange phenomenon that has found its way into our company culture.
When people come to a meeting room, they open their PC and read their emails .
There is hardly any participation in the conversation.
Cell phones and PC's are given priority over the meeting. This is a logical consequence of this availability vision. Why engage in a difficult conversation if there is also a machine with buttons available?

How do we solve this?

Again, solutions are formulated that sound good, but excel in naivety. Banning the use of mobile phone and PC in meetings is such a naïve proposal. If someone is not interested in a conversation, he will find a way to get hands on his PC or cell. We need to find a way to get Melvin's attention in a Melvin way.

I propose to use provocative penguin math. Penguin math goes as follows .

On the picture 5 penguins are walking towards the water. The last one wonders how long it takes before he can take a dive. There are 4 penguins in front of him. Every 30 seconds one dives into the water. So the last penguin knows he should wait 2 minutes. Enough time to lie down. I call this penguin math because it is intuitive. We use the same logic when we queue up for an attraction in an amusement park. It is important to use only numbers that are intuitively clear. After all we want Melvin to close his PC and start the conversation. You don't get that with a complicated excel sent via email.

pinguin math

The figures must also be provocative. This means that they should touch on problems that put the lack of collaboration on the table . For example: We have done half of the sprints and delivered only 25% of the user stories . This leads to a discussion about delivery versus commitment. Surely some people will get worried here. This is exactly what we want to achieve!

Example of a discussion on planning, triggered by two figures :

    • "Team": ok, but most of other 25% user stories are almost finished. In fact, they are 90% complete.
    • "Agile craftsman": and can we just include those user stories in the next sprints. Is this feasible as parallel tasks?

Example of a discussion about complexity, triggered by the same figures

    • "Team": ok, but the delivered user stories are the most difficult ones. The other 75% will go a lot faster.
    • "Agile craftsman": are the first 25% overrated and the last 75% underestimated? How do we determine complexity?

In the same way, we can present figures around test- and development lead times. These figures bring test driven development and test automation to the table.

Why only figures on Duration and not on Effort ?

We put the focus on Duration (lead time) and not on Effort for a particular reason. We want the team to focus on delivery and not on being busy.
With a focus on effort, the Melvin in us can retire
to his apartment and do his thing in the agreed number of mandays.
For delivering a product (measured in duration of delivery) he has to collaborate with others.
But we should express capacity in number of delivered user stories and not in spent mandays.
By measuring capacity this way, Melvin is measured against his capacity to collaborate.

The hard way and its comfort zone

The hard way has its risks as shown in this diagram. By provoking Melvin he might quit.
Maybe at one time he’s so fed up with the barbarians in his apartment that he will abandon the agile initiative.
That’s a risk we should be aware of.

chart v1b

I want to be updated when the next publication is released:

Upcoming publication: [07.07.2020]
"Define business value in agile"