Agile development is based on iterative and incremental development (IID). IID provides regular feedback by breaking the project into iterations that are generally one to four weeks in length. The output of each iteration is working software. Each iteration is like a stand-alone project ending after the fixed time-box, and delivering some executable version of the product.

Iterative development has been around for decades. As far back as 1987 Fred Brooks' as chairman of the Defense Science Board Task Force on Military Software recommended that the waterfall process be replaced with iterative development due to waterfall's history of failure on large DoD contracts. Iterative development has been used successfully on some very high profile projects from the 1950's to present day including: the X-15 rocket plane, project mercury, trident missile submarine control systems, the space shuttle avionics, and the Canadian Automated Air Traffic Control System, to name a few.

The problem with plan driven development, rather than feedback driven planning, is that in the former the fact that new invention is happening is not recognized and acknowledged. You can't schedule inventions and discoveries. You can schedule trials and review milestones, but you can't schedule invention and a lot of software development is invention.

What's wrong with how plans are created and used?

One of the problems with getting software done is that project planning is often based more on what is desired rather than what is possible. What is desired is very important, don't get us wrong. Dates drive business and dates are often set for very good reasons. For example there is a trade show where your product needs to be showcased, you know that the show must go on, it won't be rescheduled just because your product is late. Or your company may have a competitive threat where time to market is critical or maybe the revenue for the big order cannot be recognized until the product is shipped with software.

Too often the desired date and a few vague "requirements" are the only information provided when starting a project. Model 2 is being retired in 9 months, so we have to have model 3 ready in 8 months with these new features X, Y and Z to get the big sale with Acme. That is critical information, but we also need to know what is possible when planning a project.

Acording to Steve McConnell "Software projects contain too many variable to be able to set schedules with 100-percent accuracy. Far from having one particular date when a project would finish, for any given project there is a range of completion dates, of which some are more likely and some are less." Steve McConnell from Rapid Development.

We need a realistic planning mechanism that allows the business to make informed business decisions. The obscure black art of software planning and development has to be made more transparent, and measurable. The inherent uncertainty has to be recognized and dealt with.

What is Agile Planning?

The plan becomes more accurate as the team learns more about the project requirements, the solution design and implementation, as well as learning how to work together. The plan is also very flexible, with the content being negotiable for all the future iterations. As market needs and team knowledge change the plan can be adjusted as necessary.

How is work divided on a Agile Team?

There are two main roles in agile development, the customer role, and the developer role. On all but the smallest projects each role is usually represented by a team of people. The customer defines the product and the business goals and the developer builds the product. Customer and developer teams collaborate to deliver products. Each team has their own detailed practices.  To be the most successful using iterative development, the whole organizations should be involved.