Q
Problem solve Get help with specific problems with your technologies, process and projects.

Contract negotiation: Agile development and defining requirements up front

In this response, expert Lisa Crispin explains how experienced Agile teams can negotiate contracts that satisfy customers while also ensuring all necessary development and testing activities are completed.

When working with contractors giving fixed-bid pricing, it’s necessary to define requirements up front. Can an...

Agile methodology be used for these types of situations?

Whether we work on a contractual basis or develop software in-house, we need to accommodate the reality of today’s business environment. Priorities change on a daily basis. A fixed-price contract with requirements fixed up front doesn’t make sense. If the cost of a new software feature must be fixed, then the scope must be flexible. Agile development actually works well for this situation, because the requirements can be defined at the “last responsible moment,” so that the software meets customer needs as closely as possible.

Before your Agile team wants to take on a fixed-price contract, it needs enough experience to be able to assign a price to a unit of work. Teams who aren’t experienced with good software practices such as test-driven development, specification by example, continuous integration, refactoring, and pair programming or code reviews should not attempt to do work on a fixed-price basis. Having the customer available at all times to collaborate and make decisions is an essential component to succeeding -- of course, that’s true with any project.

Meet with the customer to understand the product they want. Elicit examples, draw prototypes and flow diagrams on the whiteboard, learn enough to judge whether your team can deliver enough value for the price, and whether the customer will be able to work with you in an Agile way. There’s no point in taking on work for a customer who cannot understand the reality of software development: estimates are only guesses, we can only measure the work we’ve completed, and priorities are bound to change.

The customer and development team can agree on a statement of work setting the budget, an overview of the product with some initial requirements, and possibly a target completion date. They should decide on deliverables. The development team should educate the customer on alternatives. For example, documentation can take the form of automated tests or “living documentation.” Set reasonable expectations. In Agile development, a story isn’t done until all testing activities, including exploratory testing, are complete. The customer should understand what they are paying for. If the customer wants to cut corners and asks the development team to skip essential activities, you might not want to take on that contract -- do you want a reputation for delivering software that’s unreliable and hard to maintain?

If the team uses iterations, they can get with the customer before each iteration to plan the stories. Or, the team can take a lean or kanban approach and pull stories in as others are completed, based on the customer’s latest priorities. Make the process visible to the customer and explain how they can see the current progress at any time, by looking at big visible charts and test results.

Your team needs good ways to track both planned and completed work. For example, if the team is producing a Web application, user stories can be mapped out on the whiteboard. The team can work on the stories according to the customer’s current priorities, tracking the time spent on each. When a user story is complete, the team can post a screenshot or other representation of the completed story and note the cost. Anyone can know the current status with a quick look at the board. This can be done with online tools as well.

As soon as the first user story is complete, the customer has working, release-ready software, supported by tests and other agreed-upon deliverables such as documentation. The customer can adjust priorities, considering the amount left in the budget, and continue to take delivery of high-quality software that provides business value. Once the budget has been spent, the customer can decide whether to continue with a new contract.

This was last published in June 2011

Dig Deeper on Software Requirements Management

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Quote from the article:
"A fixed-price contract with requirements fixed up front doesn’t make sense."
I guess, at this point the hypothetical customer turns around and leaves.

Instead, why not start a conversation about what the customer is trying to achieve? What problems they're hoping to solve with the software? What value to gain?
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close