Key takeaways
|
The Agile development process promises benefits, but large enterprises are having a hard time finding an 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-time completion of work. Challenges ensue because enterprises have certain project criteria that must be met, such as:
- Taking audit and compliance regulations into account
- Creating business cases with a well-defined scope to secure funding
- Taking a wide swathe of stakeholders beyond the user into account, such as legal, marketing and operations
“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.
1. No requirements required.
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:
- Identifying business rules
- Conducting stakeholder analysis
- Determining and articulating business needs and objectives
- Securing funding for the project
- Capturing and analyzing business processes
- Defining the scope of the solution
- Creating and defending a business case
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 providing the remaining detail in later iterations.
2. Who needs business needs? User stories will do.
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.
3. Compliance and audit requirements? All you need is user stories.
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 compliance and visibility at every stage of the project.
Compliance documents can be incrementally built. This requires a repository or single source of truth that can be used as the reference point for the document. Using a repository for information allows documents to be reproduced and updated on a regular basis. At the completion of iterations, tracing the user stories back to the original requirement provides confidence that you have sufficiently covered the requirement and the resulting work is compliant.
4. Prepare for business overhaul when Enterprise Agile comes along.
With project management, it’s a constant cost-benefit analysis – regardless of whether the project involves Agile or not. Project managers are always looking to measure progress against expected outcomes and reduce risk.
The fact is that different data will be used by each level of management 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 burn-up charts will be used as the basis to make the same decisions.
5. We don’t need business analysis – it bogs us down.
Business analysis and requirements definition are not the same thing. The error in believing this resultsin the fallacy: “If, with Agile, we are to do away with requirements, then we can do away with business analysis as well.” But business analysis isn’t simply the “gathering” of requirements, like the picking of berries off a bush. Nor is it a “one and done” proposition. 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.
A business analyst’s job is to define and manage requirements, understand their relationships, and assess their impact on the business. Strong business analysis is needed in all projects – to continuously create, analyze, and improve requirements. And in Enterprise Agile, this work remains as important as ever. It remains a critical ongoing activity throughout the project’s lifecycle.
6. No requirements software needed.
When Enterprise Agile processes are supported by a requirements application that integrates the Agile development group and the rest of the business, they have the best chance of success.
As was noted above, Agile doesn’t mean “no requirements.” Rather, it 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, in sync with the development team’s short sprints. 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.
Enable Collaboration for Greater Success
Organizations adopt an Agile framework because it offers speed of delivery, but a great deal of work must be done between implementation and success. Agile development environments are iterative in nature, with the minimal effective workload delivered just in time – but that doesn’t mean skipping crucial details. Believing any one of the six misconceptions listed above can set you up for failure. User stories, requirements definition and collaboration are all vital aspects of the Agile journey, as are traceability and regulatory compliance. Requirements software is able to get all stakeholders on the same page for effective collaboration and a more thorough development process. Proper advance planning and a real understand of what’s needed will help create first-time success and avoid rework.
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.
