The Agile development process promises benefits, but large enterprises are having a hard time findingan Agile approach that works within their environment.It’s radically different from the waterfall method of application development and delivery, incremental in its approach and focused on just-in-timecompletion of work. Challenges ensue because enterprises have certain project criteria that must be met, such as:
“The Impacts Of Missed Requirements In Agile Delivery,” a recent study by Forrester, explored the root causes of missed requirements in Agile adoption and the tangible business benefits organizations could achieve with better management tools. 96 percent of respondents reported problems in software development projects due to missed requirements, and 60 percent expected increased customer satisfaction from faster delivery as a result of avoiding missing requirements.
IT and business leaders need to discern between fact and fiction when it comes to making Agile work in the enterprise. Here are the six most common misconceptions organization should address when implementing Enterprise Agile practices.
There are definite pluses to Enterprise Agile, but freedom from requirements is not one of them. Critical discovery and scoping is still required, though the level of detail can be scaled back to only what’s necessary to make business-level decisions. But make no mistake–there are critical elements that require explicit definition, such as:
These elements provide information that the business needs to make key decisions. A certain amount of up-front analysis work is needed to lay a solid requirements foundation, but teams do not have to sacrifice or abandon agility because of it.
A key tenet of Agile is that of “simplicity”: maximizing the amount of work not done.
A business analyst in an Enterprise Agile implementation can provide just enough detail (and no less) to establish the scope and business needs while providingthe remaining detail inlater iterations.
From a user’s perspective, user stories offer a powerful view into the granular pieces of the application – but it’s only one perspective. While crucial, it’s not the only perspective. Other stakeholders such as product managers, executives, finance staff and those who will maintain, operate and support the application have different needs. And many of these needs manifest as non-functional requirements or constraints on the application.
Another reason that user stories alone are inadequate is that they lack abstraction – the ability to provide the different views that the business needs, either by abstracting up many levels to get the big picture or drilling down many levels into the details. User stories alone are limited in their ability to do this, compared to other approaches and techniques.Visual modeling, simulation and Business Process Management (BPM) can help convey business needs. These lightweight models can be done easily by hand or with technology.
When it comes to ensuring that what is developed and deployed will meet or exceed audit and compliance requirements, there are two primary reasons why user stories cannot be relied on. First, user stories are temporary. Once implemented, they are discarded. Second, user stories lack any inherent traceability, meaning even if they were kept, there is no direct, easily identifiable link between user story content and specific application features.
Persistent, traceable requirements in the enterprise become a mandate in the face of audit and compliance – whether driven by internal or external forces. One effective way to accommodate this is with requirements technologies that automate traceability and auditability, ensuring proof of complianceand visibility at every stage of the project.
Compliance documents can be incrementally built.
