Death By Customer

and so we pulled the developers’ teeth out to reduce snack time breaks

On paper, at least, the world of software development has come a long way in the last 15 years. It’s gotten so that I can’t actually remember the sleepless nights worrying about quality of output, release deadlines or scope creep. Now that everything is a series of continuously flowing tiny adjustments, the only issues big enough to fret about are the commute to the office, where to go for lunch, and wave after wave of half-baked delivery concepts that misappropriate a good idea and turn it into something so life-draining it should be considered for use in infantry warfare.

I know nothing is perfect, but why is it we have to spend so much time protecting the progress that has been made from stupid ideas?

Like, oh I don’t know, the Agile Coach, for example.

Forgive me while I get my Jane Austen on:

It is a truth universally acknowledged, that a single development team in possession of some requirements must be in want of a coach.

She may not have said those exact words, but I know she was thinking it.

So there’s a team. And someone has asked them to build something. And because it’s 2018 and everyone knows that amazon and google and spotify, and whoever else is flavour of the month, can build things in minutes that are awesome and never break, there’s an expectation that the team should be agile.

Or better still digitally agile.

Leveragely digitally agile.

And they’ve not really been agile. They build things in months, that are not awesome and that break.

So they must need a coach who’s read an agile book. Because this clueless bunch of halfwits can’t be trusted.

Before I launch into one of my customary rants, let me try and devil’s advocate myself.

There is this thing people call agile. And it’s used as a short hand for all the things amazon and google and spotify, and whoever else is flavour of the month, do. The details aren’t important. Whatever it is, the dev team don’t seem to be doing it. And yet I can order a pair of wellies at 2am on my iPad in bed and they arrive the next day. Our business wants a new app for the call centre and these muppets keep saying it’s complicated and the scope isn’t clear and they have all these other things to do that don’t really sound very agile.

Agile comes with a lot of other words that sound complicated so if we are going to get this call centre app built the team is going to need someone in it who already understands the words. A coach. It’s either a coach or we hire an actual coach to drive the dev team off Beachy Head.

Fine. I get the point. If you want to be great at golf you might very well hire a coach. Coaches and trainers and instructors can transform you. Someone said to me the other day that they’d had a trainer that limited their instruction and insight only to the level the trainer thought they could achieve i.e. I think you’re maybe a 6/10, so that’s where I’ll aim to get you. And when they changed to a new trainer who removed that artificial restriction and aimed for 10/10 they transformed. I find that quite profound. Believing in yourself is clearly important, but when someone else believes in you, even if initially that belief isn’t grounded in anything, you can be more than you were.

And so back to our team of donkey dipshit developers.

Is it true that they know nothing? As Gilfoyle would say, the fuck it is. I’ve met plenty of developers who couldn’t tell a spike from a sprint or a pair from a pear and every time it’s been because access to understanding and free thought was in some way discouraged by their environment.

I’m going to take a leap here and say that most teams have always understood all the various bits of what we like to call agile, it’s just they weren’t allowed to do them because they weren’t part of The Process. There was a process, and it restricted them to a 6/10.

I said the details of agile weren’t important and for the purposes of this post they aren’t. But I can’t really swashbuckle my way through this without defining at least some aspects of it.

When the creators of the agile manifesto got together it was because they all had something in common. They had all been experimenting with ways to break through the clumsy processes and received wisdom that made up software delivery in the 90s. Many of these experiments (pair programming, test-driven development, continuous integration) were practices that require some skill to master. But they are just practices to achieve an end. And ends can be achieved in many ways. There is no canon. Only a continuous learning process.

Two points to dwell on here: this isn’t sport, where continuous learning has a clearer target. Many of the measures might feel the same (do things faster) but we aren’t talking about mind and muscle. And sport doesn’t come with the same obstacles. The location of the finish line doesn’t change in the middle of the race. You absolutely can get better at it, but those improvements come in the form of leaps of insight.

And the other point is even more basic. What do we really want from work? I’ll offer up two things: to add value to whatever’s happening and to be valued while doing it. That is, if we aren’t making a contribution then we might as well not be there. Lazy days aside, nobody wants to waste a third of their life staring pointlessly at a computer. Life is short. We will not pass this way again. I think I’m on safe ground assuming that feeling like you helped make a thing a thing is a major objective. And when the thing becomes a thing, it’s pretty sweet if that’s recognised. The feeling that your business sees what you did and knows it, is surely related in our brains to the trainer that sets no limits to what you can achieve.

Workplaces aren’t the way they should be because of all the shit humans bring to it. Emotional baggage is how we get these processes that prevent agility. Agility is less about teaching something new and more about unlocking the things we’ve always known deep down are true. Things that The Process denied.

The process kills agility. So things don’t go well. So obviously it’s the development team who are idiots. Finally management gives in and agrees that the process needs to change. The first mistake they make is not talking to the team they already have (why would they? they’re idiots). And so the Agile Consultants show up.

Going from one state (The Process) to a slick delivery pipeline is hard. Very hard in some cases. But it can be broken into small steps. Steps that should be about some technical things, like how to take a monolithic application that can only handle two releases a year, and break it up into smaller chunks that can be released many times a day. And steps that involve many more touchy feely things, like how can this place be made into a decent environment to work.

Can it not actually be fun? With value to be added and with added-value valued? The fuck it can.

Software development is not sport. There are no absolutes, no ultimate rights or wrongs. No best practices. What is a coach coaching towards? A better continuous integration pipeline? That’s a developer skill and best solved by hiring and doing, not telling. Real coaching happens all the time - between peers with different skills, between more and less experienced developers. Coaching is good and useful. And lather me up and call me Shirley it actually happens quite naturally in a team that’s happy and well looked after.

But agile has all these ceremonies. Maybe that’s where we need a coach. Maybe a coach gets the team doing retrospectives and stand-ups and planning and pre-planning. Maybe the coach does a lot of observing and commenting. And maybe that’s why whenever I talk to a team that has a coach the phrase “punch them in the face” quickly comes up.

Agile ceremonies have their merits. I must have run a hundred retros for various teams over the years. I couldn’t honestly say what the perfect format of one is, or how often they should be done. I’ve worked in very high-performing teams who never have them.

It depends, it depends, it depends.

What I do know is all these things can be managed by people that already exist in the team. Just maybe with the leeway to make a few mistakes and learn without blame.

I’ve ranted about formalised agile frameworks before, in part because I think the very reason they’ve been created is to justify a range of spurious roles that would not be contemplated in any world where common sense prevailed.

I have worked with good individuals in the past who were hired as an agile coach. What I noticed is they very quickly disappeared into productive delivery roles. They became members of the team and others learned from them, or shared their own wisdom, as they went. But they were by far the exception.

In the abstruse world of making good software I think it’s the very indefinable nature of the role of a software coach that tends to attract the frauds, the talkers and the workshop lovers. People who hide their lack of delivery contribution behind a facade of insipid groupthink.

Why did I title this post “Death By Customer”, you ask? No, you did ask, I’m sure I heard that quite clearly.

Well, since you’ve pushed me on it, it’s because when organisations make change, they understandably centre everything around making the customer happy. And that is fair and lovely and as it should be.

But to make customers happy, I venture that you first have to make yourself happy. And that means being brave and ditching everything that stands in the way. Less process, not more. Learn and grow, don’t coach and measure. Humans and mistakes, not documents and blame.

The last bastion of the charlatan is the logical fallacy known as the appeal to emotion. Say agile coaches and consultants are a waste of money and you’ll get the so you don’t care about the customer refrain. It’s a semantic heartbeat away from think of the children. The vision of the company as an oiled machine with repeatable well-defined processes is a seductive one. But if I may paraphrase Chaplin, we are not machine people with machine minds and machine hearts. We are not machines. We are not cattle. We have the love of humanity in our hearts.

We care about ourselves and we care about the products we build, which means by definition we care about the customer.

Notes

• The painting is The Charlatan (The Tooth Puller) by Giovanni Domenico Tiepolo. It shows a crowd gathered around a charlatan who’s promising to cure all ills by yanking out their teeth. A pulcinella, the clown-like figure with the weird hat, is trying to get through the crowd to knock some science into the charlatan. Pulcinellas were used in 17th century art to represent wily sorts who go against conventional behaviour - e.g. Mr Punch in Punch & Judy whose name is derived from Pulcinello. Teeth-pulling (before modern dentistry) was a classic charlatan occupation as described in “Charlatans, tooth-drawing blacksmiths, and necklaces made of teeth: a (very) short history of dentistry”

• The subtitle is from the late great Terry Pratchett. It’s a quote from his dementia speech which is frankly a better read than this.