Agile Myths: Non-Functional Requirements Not Supported
Martha Graham (who was named "Dancer of the Century" by Time magazine and awarded the Presidential Medal of Freedom in 1976) once said:
"Nothing is more revealing than movement"
And I found these words surfacing in my mind when we recently had a discussion within our architecture community about how non-functional requirements (such as security and performance) should be addressed when using an Agile approach. There seems to be a common view that Agile does either nothing or very little to address them. Fortunately our Chief Architect, SI UK&I Dave Cunningham (who has first-hand experience of many large and complex Agile project deliveries) explained that this is simply not the case:
"All requirements are functional, from the perspective of the relevant actors. We should be able to express "non-functional requirements" from the perspective of the service manager, the system administrator, the security accreditor, the general user and the user with accessibility needs, just as we express the "functional requirements" from the perspective of the end users. We can employ use cases, user stories, Gherkin, etc. for all of this. But the important thing is that they are all requirements, they all need to go into the backlog (together!) and they all need to be worked on and delivered as features of the system.
In short, requirements are requirements, full stop. They all need to be handled in the same way. In the Agile world, non-functional requirements start on the left of the Kanban board and trudge over to the right just like any other user story. Any requirement needs to be realised, developed and accepted. Non-functional requirements are no different."
I would add that Agile gives you the flexibility to choose when to deliver any of the requirements in your back-log and it can be the case that some "non-functional" requirements (which may be important in the future) do not justify resource right now. One example could be scalability, as described in the comments on this post:
"I'd rather have a start-up with scaling issues than nothing done at all or find that I'm 6 months behind the competition. Fixing scaling issues can cost money but hopefully by the time you're at that point you're making money. More start-ups die from the idea never happening than from scaling issues and I'd much rather have the latter."
Mel Pullen, who is our resident expert on software for mobile devices, contributed to the debate by pointing out that so-called non-functional requirements can be more important than functional ones, saying:
"In the mobile world a slow responding app will be uninstalled"
Mel also referred to this excellent talk in which Tom Gilb describes an approach for specifying non-functional requirements which he demonstrates by showing how a seemingly un-quantifiable thing like "love" can, in fact, be quantified. Even more interesting for me though is this advice that Tom gives:
"You need to think about a problem for about a week (my maximum) and on the second week, and every week thereafter, you should be trying to change something to make something better; to deliver a little bit more quality to real people. And in doing so not only will the value be delivered, but you will learn from trying to deliver value what it takes to deliver value."
And he goes on to talk through a fascinating real-world example of a Pentagon project that had taken 11 years and was considered a total failure. The reason was that senior members of the military had to wait hours for answers to questions that they asked of the system. By adopting the "what can we do next week" approach, it was realised that the reason that senior military figures were having to wait hours for answers was that their queries were being queued behind approximately 15,000 queries being made by other users. Within one week a change was made that simply prioritised queries based on the rank of the person making them. That simple change made a massive difference to the perceived performance and value of the system.
But think about this: was the prioritisation of query by rank a functional or a non-functional requirement? Who cares! Dave Cunningham is right: requirements are requirements, full stop.
How you discover that something like prioritisation by rank is necessary functionality is a more interesting question.
It turns out that you discover it by trying to change something to make something better; to deliver a little bit more quality to real people.
It turns out that it isn't only in the world of dance that nothing is more revealing than movement.