Four Agile Tips to Eliminate Rework in Application Development

[article]
Summary:
Your applications need to meet business needs, overcome complex processes, and provide instant results to customers. And, ideally, they’ll require minimal rework on your part. The first step to success is requirements definition. Here, Filip Szymanski offers some tips from agile methods that will improve your requirements—even if you haven’t otherwise adopted agile.

Building applications that meet the needs of the business is becoming increasingly challenging, with more-complex business processes and ever-increasing amounts of data to manage. On top of that, customers today expect instant results, which creates additional time pressure and leaves no room in the application development schedule for rework. So, what can IT organizations do to make sure they build applications right the first time?

One of the keys to eliminating rework in application development is defining the right requirements up front. Requirements need to be clear and succinct, but they also must incorporate feedback from multiple stakeholders. There is much to learn about improving the usability and value of requirements from agile development methods, where user stories (really just another term for requirements) are at the heart of the process.

Below are four tips based on lessons from agile methods that will help improve the requirements definition process—even for organizations that have not adopted other agile techniques.

1. Collaborate
Agile methods teach us to involve multiple stakeholders in defining requirements in order to get the requirements right the first time. Building better integration between the testing team and other members of the project team is a key value of application development. Improved integration drives improved productivity and yields improved software quality. For instance, focusing on the end-user viewpoint is important for understanding the business need and user experience. However, it is also necessary to get feedback from the development team to understand whether the requirement is feasible from a technical standpoint. Thus, collaboration between a business analyst, end-users, developers, and testers will lead to higher-quality requirements than if the business analyst works alone.

Sharing information across silos enables constructive negotiations to take place between stakeholders with opposing opinions—before any code is written. Working out these conflicts during the requirements phase helps to eliminate the rework that comes from discovering these differences during development, testing, or production phases.

2. Be Lean
More often than not, IT organizations will not know exactly what they want at the beginning of development, and their needs will probably change during the project. For these reasons, lean software development practices allow the software development process to start without having a long and detailed requirements document that will become obsolete after a couple of weeks.

Agile methods teach us that a 400-page document is not required in order for development to begin. In an agile environment, development can start with high-level user stories with perhaps one layer of detail added.

I recommend taking a lean approach to creating requirements definition assets. Being lean does not mean doing nothing. It means that before creating an asset, the team should evaluate the value that the asset will bring to the applications team and the larger organization. For example, if a requirement is for an enhancement that has been discussed at length and is well understood, there is little value in creating an excruciatingly detailed description.

This lean approach should be integrated with methods for obtaining customer feedback and with build tests performed at different stages of the development. This way of working eliminates waste and increases flexibility, because it shifts the focus (and effort) from creating a complete set of requirements to obtaining software that fulfills all the requirements, including the ones that were not clear at the beginning of the project.

The team should also evaluate how an asset will be reused. An asset will be of higher value if it can be used to drive both development efforts and the testing process. For instance, a requirement defined using a business process management (BPM) tool can be imported into certain test management systems to ensure that the application is tested against the criteria that matter to the business.

Taking a lean approach to requirements also includes eliminating waste. By carefully organizing requirements (by functionality or by how features will be built), it becomes easier to see which ones are needed and which can be eliminated.

I also recommend standardizing the content of requirements. By providing guidance and standard templates to business analysts, the process of creating well-defined requirements that are useful to the rest of the organization becomes easier.

User Comments

5 comments
Jonathan Kupersmith's picture
Jonathan Kupersmith

So is this Agile or just sound practice. I agree with your 4 tips completely and all of these should be part of how we run projects. But to me this is not new with the popularity of Agile. Teams need to do things in smaller manageable chunks. Teams need to collaborate. The days of 400 page docs should be past us. Teams have been running projects like this for years. And if they are not they should.

Thanks for sharing.

June 7, 2011 - 9:04am
Renee Seltzer's picture
Renee Seltzer

I completely agree. I especially think it's important for companies to connect more with their end-users. Analytics tells you what happened, but not why it happened. It's important to figure out the why and apply this to your next set of designs/prototypes/IU's, etc.

I totally agree with this and wish more organizations engaged their customer and earlier in the process. "For instance, focusing on the end-user viewpoint is important for understanding the business need and user experience."

June 7, 2011 - 11:01am
Charanya Aswath's picture
Charanya Aswath

Nice article. Clear explanations. I think the biggest challenge is with documenting the requirements and documenting just enough. It is challenging to have a general guideline for documentation especially for consulting companies that deal with projects in all verticals and all scales.

June 9, 2011 - 5:23pm
Gerard Miller's picture
Gerard Miller

Hi Filip,

1. Collaborate

2. Be Lean

3. Iterate

4. Visualize

sound like Good Things To Do to me.

A comment on Visualize - In the example you gave a diagram was a better way to convey the information than text. Your point to use more tools than text is a good one. There may be other tools available for example audio, moving visual (i.e. a mini-movie) or interactive.

The key is to use these tools but keep in mind the goal: inform the user. I've seen Wired magazine table of contents that had so much color, so many different sized fonts and other wicked cool features that obscured organization of the table of contents.

Mick

June 6, 2011 - 8:17am
Chris Gangai's picture
Chris Gangai

Hello Filip,

Excellent article and agile tips! Wondering if in separate article here or else where you could describe how one could employ these tips using the HP ALM tool, specifically the requirements management functionality?

Thanks,

Chris

July 7, 2011 - 12:59pm

About the author

Filip Szymanski's picture Filip Szymanski

Filip Szymanski is director of products at HP Software and responsible for the HP Application Lifecycle Management (ALM) product line. He leads the team responsible for current and future ALM releases, including requirements, test, and defect management. Before joining HP via the Mercury Interactive acquisition, he was in technical sales, where he enabled the sales organization to sell higher revenue products and services. He holds a B.S. degree in computer engineering from Santa Clara University.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Aug 25
Aug 26
Sep 22
Oct 12