Agile at the enterprise level: Misconceptions that jeopardise success

The Agile development process promises benefits, but large enterprises are having a hard time finding an Agile approach that works within their environment. This is 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 swath 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 organisations could achieve with better management tools. 96 per cent of respondents reported problems in software development projects due to missed requirements, and 60 per cent 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 organisations 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 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:

  • Identifying business rules
  • Conducting stakeholder analysis
  • Determining and articulating business needs and objectives
  • Securing funding for the project
  • Capturing and analysing 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 and are the foundations for the requirements that will evolve during the course of the project.

A key tenet of Agile is that of “simplicity”: Maximising 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 “up front,” while deferring the remaining detail for 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.

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.

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 results in the fallacy: “If, with Agile, we are to do away with requirements up front, 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. 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.

The work of requirements definition cannot start until then. A business analyst’s job 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.

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 analyse 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.

Enable Collaboration for Greater Success

Organisations adopt an Agile framework because it offers speed of delivery, but a great deal of work must be done between implementation and success. 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.

Ruth Zive, Vice President of Marketing, Blueprint Software

Image source: Shutterstock/Sergey Nivens