In virtually every industry, larger enterprises are struggling to adapt an Agile approach that fits their environment. The root of the problem is that “pure” Agile approaches don’t address enterprise realities, including:
• Creating business cases with a well-defined scope to secure funding.
• Considering the broad range of stakeholders beyond the user, such as legal, marketing and operations.
• Accounting for audit and compliance regulations.
Forrester’s recent study, “The Impacts Of Missed Requirements In Agile Delivery,” 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.
This article helps IT and business leaders separate myth from reality 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.
Enterprise Agile Frees You From Doing Requirements Up Front
Enterprise Agile doesn’t mean a departure from requirements. Critical discovery and scoping up front 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 up-front, such as:
• Determining and articulating business needs and objectives.
• Identifying business rules.
• Conducting stakeholder analysis.
• Capturing and analyzing business processes.
• Defining the scope of the solution.
• Creating and defending a business case.
• Securing funding for the project.
These elements provide information that the business needs to make key decisions and are the foundation for the requirements that will evolve during the course of the project.
A business analyst in an Enterprise Agile implementation can provide just enough detail (and no less) to establish the scope and business needs “up front,” while deferring the remaining detail for later iterations. This directly supports the Agile principle of “simplicity”—maximizing the amount of work not done.
You Can Define Business Needs With Well-Defined User Stories
User stories offer a very powerful way to look at the granular pieces of the application, but only from a user’s viewpoint. 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.
In addition, user stories 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.
User Stories Alone Are Adequate to Support Compliance and Audit
There are two primary reasons why user stories cannot be relied on to ensure that what is developed and deployed will meet or exceed audit and compliance requirements. 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.
Audit and compliance—whether driven by internal or external forces—are reason enough to mandate persistent, traceable requirements in the enterprise. One effective way to accommodate this is with requirements technologies that automate traceability and auditability, ensuring proof of compliance and visibility at every stage of the project.
Enterprise Agile Will Drastically Change How You Run Your Business
Not so. Executives are still comparing project costs to value across a portfolio of projects and making decisions within that context. Project managers are still looking to measure progress against expected outcomes and reduce risk.
Each level of management will simply use different data to make the same decisions. For example, a project manager may use a work breakdown structure as the basis for making decisions for a traditional project. However, in an Enterprise Agile environment, product backlog burnup charts will be used as the basis to make the same decisions.
Business Analysis is an “Organizational Drag”
Underlying this idea is the misconception that business analysis equals requirements definition. And the error in thinking that ensues is, “If, with Agile, we are to do away with requirements up front, then we can do away with business analysis as well.”
Business analysis isn’t simply the “gathering” of requirements, like the picking of berries off a bush. It involves understanding the business strategy and objectives, finding and eliciting “raw” information from a multitude of sources at different levels, separating the relevant from the irrelevant, and conducting analysis to deduce a set of business needs and have them validated.
Only then can the requirements definition work begin. The work of the business analyst is to define and manage requirements and understand their relationship and impact to the business before development resources are consumed. In Enterprise Agile, this work remains as important as ever.
Enterprise Agile Will Free You From Requirements Software
Enterprise Agile processes have the best chance of success when they are supported by a requirements application that integrates the Agile development group and the rest of the business.
Agile doesn’t equal “no requirements.” It should instead be supported by a purpose-built application configured specifically for Agile environments. One that allows BAs to analyze the business and to evolve a set of system requirements iteratively over the course of the project, always in advance of ‘sprinting’ development teams. This way, it’s not just the business analyst who derives value from requirements tools, but also the business stakeholders and development team. Look for a purpose-built requirements application configured specifically for Enterprise Agile environments.
Be Agile AND Comprehensive
Don’t let these six misconceptions take you down the path toward a major Agile failure.
To accelerate the delivery of large, complex IT projects, companies that use an enterprise Agile development methodology are also seeking traceability, communication, speed, and regulatory compliance. But the greater the complexity and the larger the project team, the harder it is to scale. Requirements software geared toward Agile development helps alleviate this issue and create successful projects the first time around.