Equal Rights for Non-Functional Requirement

In our recent meet-up at the Agile Practitioner group, there was good talk about non-functional requirement testing. One of the first questions we discussed was how come non-functional requirements are second-class citizens. Usually they are patched on the app as an afterthought, and like any last effort, we botch it up.

One of the answers was that it’s a product management issue.

It is a simple prioritization issue. Requirements drop down the priority ladder, because someone, usually the product owner, has decided that they are not important enough as other requirements. For example, a security requirement – log-in reports in a financial application. True, we need security, but it’s not going to be the first thing we do, since we need to actually put the financial logic there too. And the latter takes precedence.

Simple prioritization, right?

Unfortunately, there’s a cost to that prioritization. Until something really bad happens, say, we need to provide these logs to the government tomorrow, all functional requirement will take precedence. So we either don’t get to that non-functional requirement, or we’ll get squeezed to do it in a third of the time it really takes to do it, and welcome to botch-city.

That’s one way requirements don’t get done. Here’s another. Let’s talk about availability. We need to be up 99.999999% of the time. All the time.

Our product owner would like this kind of availability, and the dev team says: good, prepare your wallet. The check contains a lot of zeros. After the product manages lifted his jaw off the floor, he says: “Well, let’s work on something cheaper, shall we?”. He just learned that non-functional requirements usually cost a lot more than regular requirements.

We assume that the product owner knows what’s best for the product. We’re expecting him to make the right decision, and therefore, we believe that he’s taking everything into consideration, and comes up with the perfect backlog.

Get ready for a surprise

Our product owner is not superman (or in our case, Lex Luthor). He cannot know everything about business, development, security, architecture, IT serviceability, database maintainability, and a whole lot more. It’s hard enough to keep in one’s head what the app is supposed to be doing…

If the product owner doesn’t understand security, he won’t know how to prioritize security features vs. the rest. And as humans go, will give attention to the familiar stuff over the unknown.

So how can we make sure that non-functional requirements get met?

Remember “whole team”?

In extreme programming, the “whole team” makes the decision, not just the product owner. As team members we should ask more questions: “Do we need authentication logging?”. If our poor product owner doesn’t know even what authentication logging means, he now has a mission  - learn and come back with an answer. And he would love it if that question also came with an estimate.

Ideally, the product owner should learn about everything required. Ideally he should have all the answers. But this is real life. We don’t know everything. Good decisions come from a team effort.

And by asking questions, seeking information, and bringing solutions together table we’ll have our democracy where all requirements are equal.

Which Part of the Glass Are We Talking About?

The CHAOS report says agile projects succeed three times more than non-agile, reports Mick Cohn. Good news, until I recalled that the CHAOS manifesto defines success as on budget, on time, and with all planned features. Show me an agile project that has all the original features in it, I dare you. Agility has change built-in, which makes the CHAOS manifesto definition a contradiction in terms.

Then the State of Agile review tells us things are on the up and up, agile-wise. And read that: 70% of those doing some kind of agile development are doing unit testing!

Not likely. They may be doing some kind of automated testing, and may call what they are doing “unit testing”, but most of them don’t.

That also applies to “scrum”. Or “agile'’.

Let me present you with my half-empty glass. One of the signs of agile’s decline, is the incorporation of “agile” into non-agile orgs in a non-agile fashion. A part of the process is taking agile terms and “fitting” them into the company’s existing culture.

The indoctrination of agile by the non-agile business changes the original meaning of the terms and the values behind them. So in most companies, “Agile” means more stand-ups, and less working software. The agile adoption starts, and sometimes ends, with communication processes, rather than the adoption of software practices. Effectiveness is  what business people understand and crave. Working software to them can be done by typing faster.

The problem, is that at some point, this kind of “agile” will fall short on the promise real “agile” made: to save the business from destructive projects. And when these failures accumulate, agile will be the scapegoat, with or without quotation marks. Then, we, the ambassadors of agile, will need to find new ways to rebuild the trust given to us by business, but lost because of misuse.

The irony is that the whole process is iterative. We’ll rename agile, show results, business will show interest, try to take over, succeed in the beginning, fail eventually, back to square one.

But these cycles take years, even decades. Hopefully we’ll be here to see the next round.

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More