In-Depth
Agile and the Fine Art of Gathering Application Requirements
Bloated enterprise systems are taking more time and money without providing what organizations really need. Learn how Agile methods can help.
By Paulo Rosado
Experience has taught many IT professionals that large systems are more complex to build, customize, and maintain. Although IT professionals have also learned that large systems are a necessity in many cases, do they really need to be as large as they are?
A 2002 study from The Standish Group ranks the usage factor of features across the average enterprise software system. Their findings show that on average only 7 percent of an enterprise application features are "always" used, 13 percent of the features are "often" used, and 16 percent are used "occasionally." That leaves 64 percent of the features in an average enterprise application as either "rarely" or "never" used.
Faced with these numbers, organizations must assess how much they are spending for application functionality that will never be used. They should work to streamline their application development, management, and deployment processes. Agile methods can help.
Why do organizations spend good money developing, purchasing and maintaining large, complex applications when they only really need half of what they are paying for?
In the case of a purchased software package, the explanation is simple. Packaged software is written generically, for many alternative cases and organizations, with a key objective to maximize market reach. Through parameterization, each organization can cross out unnecessary functionality and tailor the system, as much as possible, to its own specific needs.
When it comes to custom enterprise software, the explanation is a bit more subtle. Experience shows a vicious cycle that typically starts with the need to specify the entire scope of the application upfront. Unfortunately, it is remarkably difficult -- if not impossible -- to foresee the impact a new enterprise application will have on an organization's processes and day-to-day work.
When business stakeholders provide requirements to a business analyst, they tend to bring into play their current biases with regard to legacy and process inefficiencies. Furthermore, they tend to ask for everything they might be thinking about, since they know this may be their only chance of getting those "What if I really need it?" features into the project. Their experience with IT has taught them that if they defer functionality to a second release, they might wait many months—or even years—to get those extra features.
As a result, projects often start with a bloated scope and many features that will never be used or are inflexible if the business requirements change. Ultimately this is a tremendous waste of time and money, not only when building the first version of the application but in future maintenance as a larger system will be more expensive to maintain and evolve.
In such a scenario, "more" is "less." You can turn this around by leveraging Agile methods.
Streamlining the Process with Agile
Dramatic improvements in delivering the right features, fast and predictably, can be obtained through innovations in the way projects are sized and scoped and the use of Agile methods. Using Agile methods promises to change the economics of custom application delivery because IT only builds and the business only pays for what it needs. In addition, as organizations begin to realize the full benefits of Agile, we expect a shift in how packaged software applications will be built and delivered.
Agile practices can help you make this shift today.
To kick off an Agile project, we suggest starting with a quick, light process of scoping. Lay out the basic functional needs of the business by writing high-level user stories and use cases that can be negotiated with the business stakeholders.
In this process, experience has shown that some of those requirements will not really be needed. However, we also know that other requirements will be missed completely during this scoping process. The initial scope is a good enough starting point for an Agile project.
We use the first week(s) of an Agile project to prioritize requirements and go deeper in the analysis of the most important features. We ask questions such as:
- What are the most critical business users' profiles?
- What are the most frequent user stories or use cases that involve those users?
- Which use cases and user profiles contribute the most to the application's ROI?
With simple criteria such as these, business users are remarkably good at prioritizing. To support this process, any tool or prioritization technique like index cards, Excel spreadsheets or a purpose-built Agile project management tool will do. At the end of this exercise, you should have the top requirements to assign to the project's first iteration.
Getting the Project Requirements Right
As you proceed into the project and deliver the first iteration (usually after two to four weeks), we suggest showing a demo of the working application to the business stakeholders. This is where they start to visualize what the application will look like and the impact it will have on their processes.
At this point, we suggest discussing the outstanding requirements, or "backlog" of work, for the next two iterations. The goal is to decide whether the original priorities are still valid or not. You may find that priorities change wildly and new critical features will surface, pushing the lower-priority items down on the requirements list. As the project progresses, with demos every two weeks and constant reprioritization of the next features to be implemented, the "always" and "frequently" used features rise to the top. The less-used features will constantly be reprioritized and pushed toward the end of the priority list.
With the addition of new features, you will surely exceed your budget. This is where it pays to be transparent with your business stakeholders and keep them informed. If they want new features and are not willing to pay more, then some of the initially agreed "lower value" features have to be postponed to the next release. Using the Agile approach of delivering functionality early and often helps business users visualize their new application and make better decisions regarding tradeoffs in functionality. It is easier to negotiate these tradeoffs when the business sees working evidence that critical new features have been delivered.
This process rapidly builds trust between the IT and business team members. The business trusts you to deliver extra functionality in weeks, not months or years, and you prove this at the end of each iteration.
This way of working increases the likelihood of success. It is predictable and the users quickly adopt the resulting applications. The features that really matter are delivered on time and on budget.
During every project we always burn a bit of the budget overcoming integration surprises, third-party dependencies and new unforeseen features. Overall, we deliver the smallest possible application that extracts the maximum ROI and will be the least costly to maintain.
Less is, indeed, more.
Paulo Rosado is a founder of OutSystems and has been its CEO since 2001. At OutSystems, he has helped pioneer cutting-edge approaches to Agile methods using a combination of onshore and offshore resources focused on the delivery of composite Web applications. Paulo holds a Master's in Computer Science from Stanford University and a Computer Engineering degree from Universidade Nova, Lisbon. You can contact the author at paulo.rosado@outsystems.com