^ [[3.3 The PM2-Agile Model]] # 3.3.2 Iterations An Agile iteration is a **period of time within a project in which the Agile Project Core Team (A-PCT) produces a stable, potentially shippable part of the solution**, together with any other necessary supporting documentation or deliverables. Iterations are **timeboxed**, meaning the iteration duration is fixed, and the **scope** of the iteration’s content is **actively managed to meet that schedule**. **==Each iteration produces a product increment==** which brings the system one step closer to the final product. Within each iteration, prototypes or specific parts of the system are developed or updated. It is a bit like **‘growing’ software**. Instead of developing the system one part after another, the whole system is evolving through each cycle using the **CIR rhythm**. Each timeboxed iteration is properly **planned**. The iteration **goals are well-defined**; the **acceptance criteria are established**; and the tasks and responsibilities of participants are made clear. Additionally, progress transparency is assured through agreed-upon metrics and **methods for measuring**. Each iteration must dedicate a **portion of its time** to lay down the **foundation for the work to be accomplished in the following iteration**. This is where **Design Blocks** (a part of the Release Planning ceremony) play an important role, allowing teams to **challenge the requirements** that were received from the Product owner (PrOw) and other Business stakeholders. Within Design Blocks, **Agile Team Members (ATeMs) facilitate** a set of workshops that focus on sketching and developing **low fidelity prototypes for the future features until a common understanding is reached**. **High fidelity prototypes** are then produced and delivered so they can be **presented by the Product Owner (PrOw) to the business stakeholders for validation**, like the Business Manager (BM) or the Buisiness Implementaion Group (BIG). When the Agile Project Core Team (A-PCT) is confident and agrees upon which elements to deliver first, development can then start. **==Each iteration should implement the highest-priority Work Items and address the most critical risks==**. This ensures that every iteration **adds maximum value while reducing uncertainty**. Incremental and Iterative development are typically **combined with Continuous Integration**. As unit-tested components become available, they are integrated to **generate a build** which is then submitted for **integration testing**. Therefore, the capability of the integrated software grows as the iteration proceeds towards the iteration goals. **Regular builds** (such as daily or more frequent builds), make it **possible to break down the integration and test issues and spread them across the development cycle**. Often, the downfall of large projects is caused because all the problems are discovered at the same time during the single massive integration that occurs very late in the project cycle. The later in the project cycle, the higher is the risk that a single problem can halt the progress of the whole team using a non-Agile approach. The best and **most effective way** for an Agile Project Core Team (A-PCT) to **demonstrate tangible progress** is by **exposing the output generated in each cycle**. This enables teams to get feedback at an early stage so that they can continuously improve their understanding of what needs to be done and how to do it. In PM2-Agile, **three ways of exposing work** are considered. While the goals of these methods are similar (the ability to demonstrate progress, deliver value and collect feedback to reduce uncertainty), the cadence and the formalism required are slightly different. - **Exposure of Work Items** – This occurs when the team completes one or more **Work Items** from the Work Items List. - **Exposure at the end of an Iteration** – This occurs at the end of the Iteration and supports the **Iteration review ceremony**. It includes all the Work Items that are deemed as ready for review during that iteration. - **Release** – This is an **agreed Solution Increment**, delivered **to the client and users** so that they can **start using it as a real product**. It includes all the Done Work Items from several prior Iterations. The following sections provide additional information about each of these approaches. **Exposing Work Items** The key driver of an Agile Project Core Team (A-PCT) is the Work Items list, **prioritized by the Product Owner (PrOw)**. When the team completes an item from the list, some tangible progress is ready to be delivered to the client and valuable feedback is waiting to be collected. This cadence should be preserved throughout the iteration until the team presents the accumulated work during the Iteration Review. ![[3.3.2 Exposing Work Items.png]] **Releasing a work item** should be a fairly simple and straightforward process. A **simple deployment in a standard test environment is often sufficient**. After exposing the Work item, the Agile Team Members (ATeMs) involved in its implementation will notify the Product Owner (PrOw) and request feedback. Because it's a recurrent process, it's important to **keep it light and the formalism kept to a minimum, as the goal is to quickly collect feedback as a preparation for the Iteration Review**. In the end, it's the "sum" of all Work Items exposed that will make the Iteration Review a great Iteration Review. **Demonstrating Iteration Results** At the beginning of each iteration, the Agile Project Core Team **(A-PCT) commits to a goal** agreed with the Product Owner (PrOw). This goal guides the team throughout the implementation of a **specific set of Work Items taken from the Work Items List (WIL)**. By the end of the iteration, the team **demonstrates all the implemented Work Items** to validate if the iteration goal was achieved. As described in the previous section, each Work Item exposed contributes to a "growing" and evolving artefact. **This process continues throughout the several iterations** until a set of functionalities is **released** according to the **strategy defined by the PrOw**. ![[3.3.2 Solution "growing" towards a release.png]] While **exposing Work Items allows the team to receive quick feedback** and helps them to stay on track, it is only when the iteration ends that an evaluation is made to verify if the team was able to reach all the goals they have committed to. This **evaluation occurs in the Iteration Review**. The **Iteration Review** is a prescribed event, where a team aims to **collect feedback from the client to ensure that the Work Items are Done** (according to their Definition of Done). This event requires a certain degree of formalism. Though much of the iteration content was previously exposed and validated with some degree of confidence, a formal check for each Work Item must be performed. It's during the Iteration Review that the benefits acquired from the continuous exposure of Work items become visible. This occurs because the Agile Team Members (ATeM) can **fully demonstrate the developed Work Items** while helping the remaining stakeholders to validate them. ==Enabling the stakeholders to perform a rigorous and clear validation will result in a positive overall perception of the solution==. The Product Owner **(PrOw) provides the primary feedback for the Work Items exposed throughout the iteration**. However, ==during the **Iteration Review**, the Business Manager (BM), members of the Business Implementation Group (BIG), and other relevant stakeholders should also participate in the evaluation process==. Next: - [[3.3.3 Releases]] - [[3.4 The PM2-Agile Mindsets]]