Responding To Change Over Following A Plan

In traditional project management, by the time that the documentation is done the contracts are signed and the Microsoft project schedule is baselined, just about everything is obsolete. The project can start, and pretty soon you are doing a change order. Agile overcomes this by completing small, functional pieces of work in short periods of time call Sprints. At the end of these Sprints, between one and four weeks, the team presents a completed requirement to the stakeholders for their acceptance and feedback, giving the team and the stakeholders the ability to adjust requirements as the product develops.

This works because documenting the requirements of a software project is very difficult even with a well-documented business process to build from. Imagine what it be like to walk into a car dealer and order a car without having a model to choose from. Beyond the idea of having four wheels, and motor and brakes, it’s very difficult to specify the details. By having something tangible to look at and test drive, it is easy to adjust features such as colors, trim and horsepower. The same is true in software. Once you have an opportunity to take it for a test drive, you can tell what works for you and what doesn’t and revise as you build.