The need for agile craftsmanship:

• Episode 1: The need for agile craftsmanship
• Episode 2: Agile groundwork

 

• Episode 3: The Melvin attitude
• Episode 4: The pleasant way

EPISODE 1: THE AGILE CRAFTSMANSHIP

When using “agile” in publications and discussions, it turns out to generate a lot of emotions. The audience seems to be divided into 2 camps. The passionate (almost obsessive) lovers and the growing group of haters.

Craftsmanship is however never brought up in relation to Agile-oriented discussions. It is always seems to be associated with professions that deliver something tangible, like bread, a piece of software, etc.

At Renatio this got us thinking, as in our opinion there seems to be an obvious relation.

A roofer recently installed a new gutter on my house. The man gave me a 15 year warranty. I was intrigued. How is he able to do this?

And why can’t my agile coach give me that kind of guarantee ?

Why does it fall back into waterfall once the coach turns his back?

My roofer explained that he spends most of the time finding a solid basis for the gutter. This means cutting back rotten wood until he finds an anchor point.

At that moment it dawned on me that we’re missing this preparation in any agile changeover. Most agile changeovers are based on rotten wood. So they inevitably collapse.

The roofer told me that finding a solid basis means two things:

• First you have to understand the structure of the house.
• Secondly you have to embed the gutter on an existing anchor point.

Most agile transformations don’t start from an understanding of the existing house. It’s not deemed required! The old ways are redundant.

But they make an even bigger mistake.
They assume an anchor point that in reality doesn’t exist. They tend to make 2 unfounded bold assumptions on the existing organization.

1. Firstly it’s assumed that there exists a cross-functional basis. In other words, we assume people want to work together. That’s a wrong assumption. Most of the time people just want to do their job and do it well. The others are at best an asset you can use. At worst they’re an obstacle on the road.
   For example if you want to bring a project in production you have to
   pass IT and Ops and steerco’s. It’s a hassle.
2. Secondly we assume people know what customer value is and set priorities in function those customer value definitions.
   In most organizations people have no idea how their work contributes to customer value. And frankly it’s not their first concern.

We’re making a case for, what we call “agile craftsmanship“.
Like our roofer the agile craftsman doesn’t make assumptions on fictive anchor points. He looks for them in the existing organization. And where they don’t exist he creates them.

AGILE CRAFTSMANSHIP

To the right is what we perceive as agile coaching. This coaching can only be effective if the assumptions the runners are taking are correct.
Since this is not the case a lot of coaches lead a boring life. They spend their time hunting down anybody  in the organisation that is interested in his method. Turns out they are are rarely solicited.
Management will end up mandating the coaching. We don’t claim that agile coaching has no added value. Quite on the contrary. We do claim however that most coaching starts too quickly.
The work of an agile coach has to be preceded by the work of an agile craftsman.

Much like the roofer our agile craftsman has boots on the ground. He has extensive experience with delivering projects. He equally is involved in the existing organization. In other words, he is part of the software delivery work himself.

In the movie “As good as it gets”, the actor Jack Nicholson plays the character of a guy called Melvin. Melvin locks himself up in his apartment. He doesn’t want to work with other people. And he couldn’t care less about what he contributes to the whole. This is the customer of the agile craftsman.

If you don’t have Melvins in your organization, feel free to get some agile coaches into your organisation and start coaching right away.
Whenever you do have Melvins wandering around, you really need a craftsman who can dive into the old ways and confront Melvin with the problems of the old ways.

Agile-on-speed suffers from the problems of the old ways

Before diving into agile craftsmanship let’s look at the problems of agile-on-speed.
This is how we call Agile coaching that starts too early. Agile-on-speed creates teams that are very busy, but hardly deliver anything.

Agile-on-speed teams follow the routine and talk the lingo. The truth is that they deliver even less then their waterfall predecessors. It is considered blasphemy in the agile community. How can agile be worse than waterfall ?? It’s a taboo to say that some agile teams have lost their ability to deliver.

Since we’re craftsman, we don’t care about taboos. We find this an appealing observation.
Why does this happen? Once you dig into the issue you see two problems of the old ways popping up in the midst an the agile-on-speed initiative.

Firstly none of the team members is concerned about customer value! Just do the following experiment.

Walk into a daily meeting and try to understand what they’re talking about. I bet you that you will find them talking techy stuff.
Even worse, ask the participants whether they understand what the other one is talking about. You will see it’s not the case!
Everybody talks about his own silo-deliverables. And for sure, nobody is talking about customer value. How can a team deliver anything with customer value if nobody is talking about it? All agile methods clearly work towards delivering software with customer value. But this is the first thing the team will cast aside. Why?
Before answering this question, let’s look at the second age-old problem popping up in Agile-on-speed team. The second problem is that nobody is working together.
We find a recognizable waterfall structure in our Agile-on-speed delivery model.

The agile delivery path illustrated here, might look familiar. This is waterfall in an agile jacket. The analysts deliver their analysis in an analysis sprint. That analysis is then handed over to the design sprint for IT designers and so on. When this happens there are two ways to react.

On the one end, there’s the agile coach. He assumed that the old ways were gone, the minute he walked into the company. He raises his finger and points out the this is not agile. This should not happen on his shift. Luckily the team relied on him to eradicate the old ways. However the team is under pressure to deliver, so there’s no time to reshuffle responsibilities and make room for the motivational user stories.
Before you know, the agile coach is no longer invited in the meetings.

He’s left out, shaking his head about so much ignorance in this world. Obviously the company is not ready for his Enlighted thoughts.

On the other end, there’s the agile craftsman. In fact he’s already in the meetings, joyfully going along the old ways. He knows it’s not going to work. Still he talks the techy talk and does all the handovers.
Is he an hypocrite? Is he just pretending this will work while he secretly knows it doesn’t?
The answer is: yes. But he does one thing differently! He surfaces the problems of the old ways.

I once did a kanban exercise in such a company where collaboration and customer value was off the table. Most of the projects were delayed and everyone was extremely afraid to be blamed. We establised a kanban board and came up with 25 columns for just 8 tasks. The entire board was full of checks and balances and escalation paths. Nobody wanted to take up a task unless it was prechecked, to ensure there wasn’t any poisonous ingredient for which they might be blamed for afterwards.

Trust was non-existant. The average lead time for a modification of the website was 4 to 6 months! Every day tickets were pushed through this tediously long way of checks and escalations. Gradually it became obvious to all participants that this was ridiculous. So, change happened.
Every week a column was killed and every week the lead time improved. Eventually lead time for functional improvements were reduced to 1 1/2 month.

The most important result of all, was that collaboration increased and delivery became everybody’s focus again. Nevertheless, at that point we were still far away from an agile organization. The biggest gain was, that first anchor point was established.

Article series about Agile craftsmanship:

• Episode 1: The Agile Craftsmanship (07.04.2020)
• Episode 2: Agile groundwork (14.04.2020)
• Episode 3: The Melvin attitude (21.04.2020)
• Episode 4: The pleasant way (28.04.2020)

Previous publications

Upcoming publication: [07.07.2020]
“Define business value in agile”