The need for agile craftsmanship (Pt 2 / 4)

separator
agile craftsmanship header

The need for agile craftsmanship:

Episode 2: Agile groundwork

In the previous episode, we outlined the agile groundwork. Agile-on-speed teams do not go through this stage of groundwork.
It requires boots on the ground and some level of hypocrisy. An agile coach refuses to go down that path.
While an agile craftsman has less dogmatic impediments of the sort. The result of this agile groundwork will be an agile anchor point, from which we can initiate the following stage and move into agile coaching.

This anchor point contains the following attitudes:

  • There an actual cross-functional team that is more than the sum of it’s parts
  • The team is focussed on delivering customer value

The path to this anchor point is more difficult than generally believed. There is also an easy
path, which we will briefly discuss later on.
However in trainings this easy path is all to quickly assumed. Trainees end up disillusioned by their agile achievements. They look down on their own company as backward and unable to abandon to the old ways. This disillusion stalls any agile change process.

Renatio claims that there’s no reason to be disappointed, if you see old ways pop up in your agile initiative. This is normal and should be expected in most organisations. The difficult path is the rule.

MELVIN ATTITUDE

The agile craftsman starts from the assumption that there is, what we call "a Melvin attitude" in each one of us. This Melvin attitude prehibits collaboration. The silo-organisation is not to blame. In fact, the Melvin attitude is a silo-attitude that is deeply embedded in our thinking (1).

This Melvin attitude is twofold:

  • firstly the others are wrong
  • and secondly, if they would just do their job we wouldn’t be in this mess.
The melving attitude

(1) Some claim that one can remove silo-thinking by giving people insight into the system they are working in. There’s value in that. But it’s also a highly intellectual view. It assumes that rational insight triggers the right behaviors. We claim – together with the Agile manifesto – that one can only uncover new ways of working by doing. Agile craftsmanship is a hands-on, boots on the ground approach, which can be blamed some level pragmatic hypocrisy.

The Melvin in us

Jack Nicholson plays in the film As good as it gets a character named Melvin. Melvin is an author of love novels, but he’s not a nice guy. In this scene, Melvin is disturbed in his work by the cleaning help of a neighbor. This neighbor is sick and can no longer afford the services of the cleaning help.
Yet the woman takes the initiative to ask Melvin if he can walk the dog. He accepts this because he has to!

Melvin retreats in his apartment. He only wants contact with the outside world via a few people, including the waitress of the restaurant where he eats every day. There he only wants to eat at a certain table and served by one waitress only.

We do not want to be identified with such a man. Yet our professional attitude does not differ far from this Melvin.

Take the distinction between Business and IT.
Who is that Business? In fact, for the IT guy, Business is any person who is not IT.
The business is characterized as unreliable (regularly change ideas and blame IT) and not very professional (don't know what they want).

The same is said of the IT guy. Much is promised, but not delivered. IT-people (also called techies) generally display an arrogant attitude, according to people who are labelled Business.

Not that the world within IT is so harmonious. For example, the tester has a problematic relationship with the developer. The tester complains: the developer shows little respect for my work as a tester. I always have to show up at the last minute and then hardly have the tools to test .
The developer on his turn sees it differently. He wonders why everything has to be tested again and again.
It doesn’t bring anything. Because even when it is tested, it’s not done right . Why else would business find this many bugs? And it’s always the developer who has to solve it. He has to open the same code several times and sometimes even has to reverse previous changes .

A similar cold war is also raging between Dev and Ops. We won’t even go into that one.

This distrust is not as innocent as it seems. It has a direct impact on the lead time of the work. The previous example of the Kanban meeting in a retail company shows that this distrust will cause important delays. Because people didn’t trust each other they put around 17 checks an balance on the delivery path.
As a result the average lead time for a modification of the website was 4 to 6 months!

Two characteristics of the Melvin attitude

The Melvin in us stops us from collaborating and causes delays in our work. Moreover you can change the organization, but that won’t makes us work together.

Why is this? How do we solve this?

To solve this, we first have to understand what this Melvin attitude consists of.

A Melvin thinks about his environment in two ways:

  • The others are hell
    They always get it wrong
  • The others are availabilities
    If they would just do their jobs, we wouldn’t be in this mess.
chart v1a

This might sound like a harsh judgement on our attitude towards colleagues.
So allow me to argue this further in the next two sections. And don’t worry, I will offer some solutions.

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

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