Compromising agility

Angry old men

Clarke Ching is an angry old man. So am I.

We seem to have gotten exactly opposite messages from the same session. I can’t tell you what the intent of the session was. Gus, Simon, will you tell us more about the intent of the session?

I can only tell you what I got out of it. To be honest, I didn’t really listen to the introduction of the session, when Clarke snuck out. I was still too busy thinking about the previous session, about the concerns of business. But I got some stimulating discussions around the themes of the session.

Do I think there is a danger of compromising agility? You bet. I’ve seen several projects fail because of that. I was responsible for several of them.

If at first you fail, try again

For example, on one project I compromised on collaboration and feedback when my team was denied access to real users. We could talk to the process specialist whenever he was available, which wasn’t often. Our software just had to support the processes he had drawn up. No intermediate releases, no user testing; release everything at once at the end of the project. You can guess how this story ends: we delivered software that faithfully supported a process that was impossible to implement effectively. Looked good on paper; not so good on the work floor. The software was not put into production. What a waste of time and effort.

And this wasn’t the first time either: the previous attempt (before I arrived) was binned too. The salespeople had calculated how much time the workers could spend on each customer to make the service profitable. Just entering data about the work in that system, without doing any work for the customer, took longer than that. So, if they used this system they lost money on each customer, by definition. Major disaster. For the next attempt nothing was changed. Steady as she goes. So much for learning.

There is a better way

I was responsible for the failure. I was mad. I had nothing to lose, I was a dead man walking. Surprisingly, that customer didn’t throw me out after this disastrous project.

So, we made some changes. We no longer accepted compromises to our values. The team went to the workfloor (gemba) to see our users in action (Genchi Genbutsu) and to talk to them, to involve them in the project. We had to regain the trust we lost with all those failures. We set up shorter releases (every two months instead of every year) to get more feedback and to deliver value sooner. Three months later this application went into production. At first in a “pilot” for a limited number of products and customers. But, probably a first in this company, shortly afterwards managers and workers asked for the system to be put into full production use earlier than planned. The users gave us lots of useful feedback and each two months we delivered an improved system. Today, there is a real lean culture of continuous improvement and worker involvement on that work floor. Today, they are making money.

Compromising agile values

I’m not talking technical stuff here. Who cares if we did TDD or pair programming? I care about quality work, communication, collaboration, feedback, delivering value, steering… I care about agile values. I don’t want to compromise those, because every time I compromised them, the result was failure.

Why did I continue to work on that project, knowing full well that these compromises severely reduced the chances of this project delivering business value?

Should we go back to work and demand better? I demand better of myself.

Am I extreme? Sure. I want to do better each time, make things better than they were before. That’s why I’m in it.

I agree with what Clarke says. There’s a danger if there’s too much focus or dogmatism on the technical aspects or the practices. I know of one team who “went dark” because they had to “refactor for 6 months”, leaving their manager with absolutely no idea what they were up to. They were doing “Extreme Programming”, but not as we know it. I think we can “evaporate this cloud” by clarifying if this session was about agile practices or values.

I’m not willing to compromise my values. I demand better of myself. And, as Clarke predicted, as a result I’m out of a job 🙂

p.s. About Scum…

A few weeks ago, I had to approve a training request to send people to “Certified SCUM [sic] Master” training. Nobody else of the many people involved in this process made any remark about the name of the course. Scrum is very new in this organisation, so “scrum master’ wouldn’t be familiar to most of the people involved. If I were a manager who had to approve a request for “scum” training for my team, I would ask some questions. Does this tell us something about the value this organisation places on training and quality? Maybe. Maybe it’s just a typo.

Respect for people, that’s another one of those values…