By: Ruth Zive, Vice President of Marketing, Blueprint Software
Enterprises across all industries are embracing Agile development practices, yet finding it challenging to adapt in a way that works with their environment. Why? “Pure” Agile approaches don’t take into account such enterprise realities as: creating business cases with a well-defined scope to secure funding; including audit and compliance regulations; and considering the broad range of stakeholders beyond the user, such as legal, marketing and operations.
In “The Impacts Of Missed Requirements In Agile Delivery,” 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 can make Agile work in the enterprise if they are able to separate myth from reality. Here are the six most common misconceptions organizations need to address when implementing Enterprise Agile practices.
1. Enterprise Agile = no requirements
Critical discovery and scoping up front is still required, though the level of detail can be scaled back to include only what’s necessary to make business-level decisions. But, make no mistake – there are several critical elements that require explicit definition up-front, such as:
• Creating and defending a business case
• Securing funding for the project
• Determining and articulating business needs and objectives
• Identifying business rules
• Conducting stakeholder analysis
• Capturing and analyzing business processes
• Defining the scope of the solution
The business needs information from these elements to make key decisions; they are the foundation for the requirements that will evolve throughout the course of the project.
In an Enterprise Agile implementation, a business analyst 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”: minimizing the amount of work done.
2. Agile revolutionizes how you manage your business
Decision makers continue to evaluate projects within the context of comparing costs to value. 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 similar 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 relevant determinations.
3. Well-defined user stories define business needs just fine
There’s certainly a need for user stories; they provide a 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.
Additionally, user stories aren’t able 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.
4. Compliance and audit can be supported by user stories alone
User stories cannot be relied on to ensure that what is developed and deployed will meet or exceed audit and compliance requirements. There are two main reasons for this. 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 are needed for audit and compliance reasons – 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-compliance and visibility at every stage of the project.
5. We don’t really need business analysis
Some feel that business analysis is a drag on the organization, but 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.”
Far more than just the collecting of requirements, business analysis 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 an analysis to deduce a set of business needs and have them validated.
After this understanding and analysis, the requirements definition work can begin. The work of the business analyst is to define and manage requirements and understand their relationship to and impact upon the business before development resources are consumed. In Enterprise Agile, this work remains as important as ever.
6. You won’t need requirements software with Enterprise Agile
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..
Abandoning requirements is a recipe for disaster. Instead, Agile should 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.
Creating Agility
People believe all sorts of myths about working with Enterprise Agile, and the resulting confusion can lead to project disaster. Rather than throwing caution to the wind, organizations should adhere to best practices, especially when it comes to traceability, communication, speed and regulatory compliance. However, large, complex IT projects with large teams can be difficult to scale, which is where Agile requirements software comes to the rescue. It helps create sound projects with minimal rework by supporting Enterprise Agile processes.
About the author:
Ruth Zive is a metrics-driven marketing strategist who has worked for two decades serving B2B clients in the technology, healthcare and financial services industries. At Blueprint, Ruth is responsible for product marketing, analyst relations, branding, demand generation and inside sales initiatives.