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.
Dig Deeper on Topics Archive
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting. Continue Reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates. Continue Reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good. Continue Reading