Managing the OSCARs Using Agile
In any technology centred product or project there are 2 distinct sets of requirements; Functional and Non-Functional. Both are equally important but for different reasons. Functional requirements, related to what the offering actually does and how a user does it, are obviously important because they directly differentiate your offering form your competitors or meet a business need. Non-functional requirements are less likely to differentiate your offering during the sales phase, but once the user has moved to implementation and then BAU, they become far more important. Non-Functional Requirements (NFRs) cover areas such as Operational support, Scalability, Cybersecurity, Availability, and Resilience - the OSCARs I mentioned in the title.
A few years ago, when projects were delivered using a more waterfall approach, business support teams found it fairly easy to ensure that NFRs were captured by providing a standard set of requirements based on business criticality. Under Agile, including these can be more difficult because Agile requirements are normally captured as user stories. User stories describe the things a user will want to do with your offering (‘As a customer service manager I want to be able to check the status of a customer account to enable me to resolve a customer query’). Because NFRs can’t be easily described in this way they tend not to be correctly captured.
Missing requirements like these from a release creates a problem for the business; do you go live and try to retro fit in a later release, or delay the release of the offering until they are addressed? Because Agile emphasises fixed time and frequent releases your Agile development team may not regard this as a problem. However if, in the meantime, a customer suffers a security breach because the offering wasn’t secured or the offering fails and operations cannot quickly recover it the problem can rapidly become one of brand reputation.
Agile does have ways to avoid this problem, but not all Agile implementations include these. Options include:
1. Make them part of user story acceptance criteria
By referencing NFRs in the acceptance criteria for a user story it becomes implicit. This fits well for performance requirements (‘As a user I want a request submitted to the web portal answered within 3 seconds’) but doesn’t work so well when a NFR affects multiple use cases.
2. Create a new user and add user stories
If you consider a role such as CISO and add user stories related to their area of responsibility you can make implicit requirements explicit. For example ‘As the CISO I want to be able to successfully pass penetration testing to ensure our product will not expose a customer to common cyber threats’.
3. Create a Technical Story
There is a lesser known type of user story called a Technical Story. These are effectively user stories where the product or service under development is the user. They should be prioritised and handled in the same way as other user stories.
The problem I’ve described above is a common one encountered when introducing Agile, and illustrates the difficulty that can be encountered if Agile isn’t effectively implemented and properly integrated into your end to end business workflows. Get it right and the OSCARs will be one less thing for you to worry about.
Because we’re methodology agnostic, Pragmatist Consulting can help you overcome challenges like these to more effectively transition and, importantly, successfully integrate, new methodologies into your existing business operations. Doing this will help you better achieve the expected benefits whilst shortening your transition period. Contact us to discuss your challenge and find out how we can help you.
Pragmatist Consulting provides a pragmatic, emotionally intelligent business and change consultancy service which we tailor to fit your need. We focus on helping you turn your business problem into a success story.
16 April 2020