## 4.8 Evolution & Change The Evolution and Change dimension of a project highlights the need to recognise and to welcome the natural evolution of the project scope. As a project progresses, both the provider and requestor organisations gain a better understanding of the problem to be tackled and how to address it. As PM2-Agile enhances and extends the PM2 methodology, changes that seriously impact the development aspect of the project should be **managed within the overall project change management process**. Agile Team members (ATeM) should also participate to ensure proper understanding of the change requests. From a specific PM2-Agile perspective, it is important to ensure that ==change requests are translated into the corresponding Work Items that will populate the Work Items List (WIL)==. Those Work Items will be prioritised and later implemented in the scope of one or more iterations. PM2-Agile addresses the natural and expected evolution and change during the project through **Release Planning** and **Iterative and Incremental Development** practices. The **Release Planning** practice focusses on the high-level (macro) planning of the complete known project scope. Each planned release includes all the work items to be released and describes when they will be implemented across the several iterations. It is based on the notion of creating a project coarse-grained plan and use it to guide the development of fine-grained plans for each iteration. As such, it’s clear that a properly estimated and prioritized Work Items List (WIL) is critical to ensure proper release planning. Release Planning is a continuous effort that should reflect the team’s growing knowledge of the solution. This effort improves the accuracy of project planning, delivering updated Release Plans that clearly show what the team expects to deliver in each planned release. When adopting Release Planning, the Agile Project Core Team (A-PCT) can better adjust itself as a response to the need of increasing manpower. Also, Release Planning makes it visible to the [[PrOw]] how the solution is evolving, giving him enough time to react in case things don’t go as initially planned. The ==Release Plan is the main output of the Release Planning activity. Part of the Development Workplan==, It’s a key element for managing the evolution and change within the development aspect of a project and to communicate progress and trends to senior management. For more information about the Release Plan please check section [[7.2.2.2 Release Plan]]. The **Iterative and Incremental Development** practices describe how to create a solution in increments while repeating/refining a cycle over and over again to collect feedback and adjust accordingly. **Incremental Development** is a pattern used by most of the projects. It is based on the idea that a system is built in a series of increments and each increment adds a subset of the final system’s functionality. The system grows to become more and more complete over the course of the project’s iterations. The alternative to Incremental Development would be to develop the entire system with a unique, big-bang integration at the end. PM2-Agile relies on Incremental development as a ==great tool to facilitate planning as it breaks up the solution and organises it according to a specific strategy==. This is the foundation for a solid Release Planning activity. **Iterative Development** is based on the idea that time must be put aside to ==review and improve parts of the system based on the feedback from the stakeholders and the self-learning process of the team==. The alternative strategy to Iterative Development would be to get everything right the first time. In PM2-Agile all iterations are timeboxed and with the same duration. This is important for three reasons: - Establishes the ‘heartbeat’ of the project. - Reduces overall uncertainty (there are many things that cannot be predicted, but we can control when an iteration ends). - Helps understanding the project team’s performance. Working in small and regular Iterations is a great way to collect valuable feedback. **Regular** ensures that the team doesn’t go off limits and **small** makes is easier to apply the necessary changes resulting from the feedback. Small and regular Iterations also support the teams in postponing design decisions to the last responsible moment (referred to as Set Based Design). Those iterations are very important learning cycles that help the team narrowing down their options as they progress, instead of taking all those decisions right from the beginning, when there’s not enough information available.