“Honey, did you get the napalm?” Or, Why the Requirements Suck

When you’re in a service industry, the usual client path starts the same, regardless of your particular branch of business. You approach them, or they reach out for you. Then, they send what they want. Then you employ your craftsmanship, providing them with adequate value for money. In most of the world, that is – sorry, North Korea and Cuba! And while you do it, things suddenly change. When you’re a car mechanic, it turns out that the actual fault is not the gearbox linkage, it’s the clutch worn out by the idiot owner. So, you contact the client and change the clutch. Then you make an order for a new clutch at a ridiculous discount. When you’re in interior design, it turns out that some, meticulously selected, shade of paint makes the man of the house look stupid every sunny evening. So, the client contacts you and you pick a new paint. One that makes him look like an orange, which is a noticeable upgrade to his dubious appeal. When you’re a hairdresser, it turns out your hipster customer looks like a Thailand-made lumberjack wannabe with his beard trimmed at 25 millimetres. So, you discuss the matter with him and turn him into a clean shaved man. A skinny, useless, and weak one – but a man. It seems ridiculously easy and it is. That’s how service business works all around the globe.

Not in software development industry, though.

For some reasons, apparently unbeknownst to the wisest of elders, this specific area is particularly resistant to change of requirements. Even with the Agile movement, Scrum, and plethora of organisations doing whatever they can to profit from it, the terrifying majority of development rests stuck in the safely zone of their fixed scope umbrella. Yes, there’s the reality meteorite plunging down the sky at ludicrous velocity and things are to get at least, well, complicated, at one point, but – it’s not here yet! We can all indulge in the safety of our comfort zone. For a while. Just a release or two. Or just a few sprints. Just one? Oh, well. It will do.

The terrifying failure of the whole Agile thing is its fixation on product delivery. Yes, it is much better than the ridiculed reality of the biggest of biggest corporations – or a small, EU grant driven pump and dump software house – being projects delivery. It was really too easy to ridicule. There’s the (stupid) running joke amongst the false prophets of Agile – that the goal of a project is to deliver a project. Well, perhaps, in a hugely misunderstood world of software. It does make sense in quite a lot of places outside is. That is, given these projects are properly defined. And understood. And funded. And justified.

Agile made a bold move to switch to the product delivery. Apparently, it is no longer about delivering a project. It is a product. So, the initial scope is of not really that relevant. We iterate the Plan-Do-Check-Act, we adapt along the way, the limits of our initial ideas no longer bind us!

Well, really?

Yeah, tell that to your client’s legal team. Please, go ahead and tell them now. And now that you did, you’re unable to read this text any longer, as they swarmed you, as useless fashion bloggers would swarm the next Kim wearing the next best outfit of the week. And I don’t mean the North Korean Kim.

But it’s not really about legalese. There are plenty of folks out there finding really creative ways around that. Yes, that’s including lawyers. And I was surprised too, so put no blame on yourself.
The biggest problem lies at the thin line separating vendors from the buyers. Let me give you an example, one as embossed in every adult’s life as humanly possible. Your spouse asks you to pick up some groceries on your way home. Just a few. Not enough to justify making a list. Say, three items. So, you drive along and stop by the shop. You walk in and stroll across the aisles. Then you pick up a travel bag, a shovel, and some cool aid. Then you walk to the register, pay and leave.

Notice what happened. You’re the buyer. You got what you wanted, paid for it, and left. The salesman is the vendor. Gave you what you asked for, charged you for it, let you leave. Business as usual. There’s no reason for anyone to be unhappy, right? Then you return home and kiss your spouse, only to be greeted with one question that should ring quite a lot of bells in your head.

“Honey, did you get the napalm?”


So, your list of somewhat unorthodox groceries should make you think. It didn’t. The business you and your spouse are dealing with should make you think. Somehow, it didn’t. The fact that one of you is called Frank and the other Claire, really, should give you some hint. Yet again, it didn’t.

Odds are, it’s quite a lot like your recent Agile project.

You just forgot about the obvious. And the vendor forgot the obvious. They’re not in the selling stuff business. They’re in service business. Truth be told, we all are. Products are utterly irrelevant. What people can achieve with them, matters the most. A pen can be useless when I don’t need to write anything. It can be worth some small amount of money when I’m bored to death waiting for my spouse. Then again, it can be worth everything in the world if I need to perform an emergency tracheotomy on some unlucky roadster owner, who peeked a bit too far off the windshield and swallowed a bee.

It’s the thing to achieve that matters. It’s never a product. It’s always a service, nothing else. And yet, we all mistake them regularly, both as buyers and as vendors. We just need some physical construct to envelop our needs. The ‘physical’ part makes beautiful irony in the software world, but still.

Focused on these constructs, we all forget the service part. That’s what every software buyer does. We just cannot think of everything. There’s always something that lies forgotten. We are humans, we make mistakes. That makes us normal people. There are some vendors, that look deep and your eyes and say, with their eyes glittering “I’d bet you need some Magnesium pills. Or some shotgun shells. Or that additional popup window.” The very few that can engage you, understand your need, reach out, and provide.

Be one of them.

So, next time some buyer contacts you about some software they need, make no mistake.

Offer them some napalm.

Opinions are my own and not the views of my employers, customers, or clients.

Failed Agile Transformations ebook

Learn how to spot, avoid, and FIX them!