Planning

Management typically assumes that project members will need a specific amount of time to plan an application and some more time to develop it so that when the deadline arises, they will (hopefully) be able to present a running system.

Note: An agile process intends to present a running system not only at the end of the project, but also at the first release, after three months, at the latest, and then regularly after every release cycle.

This requires a completely different kind of planning. For instance, we cannot expect a final plan at the beginning of a project. Instead, planning will be an ongoing task. Furthermore, a typical plan based on components will not help us any further. The main difference is that such a component-based plan considers mainly (if not only) dependencies and does not focus on an application that is almost always able to run.

Note: The idea of agile processes is to deliver early and often.

Of course, it is also important to ensure that the deliverables always cover the current highest business value for the customer. In each iteration, a complete base functionality should be developed, whereas, at the end of a release, the complete domain functionality should be available for use by the customer.

Therefore, at the beginning of each development cycle, the customer is required to define the functionality that provides the highest business value. The evaluation of the functionalities could change over time. For example, according to a shift in the market, the customer might prefer one functionality over another one. Also, it may be more important for the customer to see the main function running earlier than the optional behavior. However, the decision is always the project manager’s. When the plan relies instead on components, it does not typically make a difference if functionality has the main part and several optional ones because the unit under the plan is the complete component.