Software Requirements are Business Requirements

Software and technology are bringing a lot of changes to our lives - just think of the things in the news set to make waves in the near future - robots, AI, blockchain, and self-driving vehicles.

If only part of the revolutionary claims for this tech comes true, the world will look very different.

It's exciting.

This cocktail of technologies brings a lot of opportunity as well a great deal of upheaval.

One thing I've noticed about this digitally transformed world: every technical requirement of a project is also a business requirement.

I've often heard these words spoken: "That's just technical detail."

But I agree with less and less as time goes on.

It sounds wrong now. Just a technical detail? What product are we building here?

Yet it's true, in a way. It is a technical detail. But that doesn't mean that it isn't important or you can just ignore it or you can pretend to ignore it until it becomes a problem.

So how do we deal with this?

Over time we'll all benefit from current changes in eduction - more focus on reasoning, outcomes, and learning code will help. More people who know what code is and who have written a line or two will help demystify the whole thing a bit.

Business people: You need technical awareness and patience and you need to ask the good questions. Again, eduction will help.

Technical people: You also need patience and improved listening and communication skills. I've written before about the pain of the unasked question. Ignoring hard questions because you don't like the answer isn't OK. Ask the question you know is there.

We all need to get better at explaining trade-offs in non-technical ways. This really shouldn't be that hard.

But what is the quickest fix? What can happen now? Where do I see people stumble?

The answer is more agile adoption and commitment to great product owners.

I'm currently reading Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland. Here's their quote, that I like the best on this. The Product Owner:

Needed to spend half their time talking to people buying the product (getting their thoughts on the latest incremental release and how it delivered value) and half their time with the team creating the Backlog (showing them what the customers valued and what they didn't).

That would definitely help a team move fast and understand the right technical/business requirements very quickly.

It's why I believe so strongly that Agile is the right methodology and that following as closely as possible to the recommendations makes sense. I've seen a lot of product owners who did a lot of the first or a lot of the second, but only a few who did a great job of balancing both (and who were given the organizational bandwidth and charter to do it).

Today everything - every part of an application - is a business requirement. Waiting around for business experts to answer questions, when they have many other responsibilities, is a delay that almost no one can afford any more.

We all have to go fast.

And we all need the business expertise and customer awareness built into our teams.