### 7.2.1 Development Handbook The Development Handbook documents the selected **approach for developing** the information system (as part of the overall solution) and how the domain-specific aspect of the project relates to the overall project level. The Development Handbook **is an extension of the Project Handbook** and should be **aligned** with the key controlling processes, project policies, rules and overall management approach described. The Development Handbook is identified as a separate artefact but does not have to be a separate information carrier. Depending on the project’s nature, there might be a single container for both artefacts and even a synchronised configuration management. The Development Handbook extends the following areas of the Project Handbook. - **Roles & responsibilities** – Documents any deviations from the standard PM2-Agile Roles and the standard RASCI table of responsibilities. - **Project management plans** – Ensures that important information related to the Agile development aspect of the project is considered and documented in the PM2 management plans, such as the selected approach to managing risks that are domain-specific but that may need to be visible and managed at the project level. - **Domain-specific artefacts** – Identifies which Agile-specific artefacts will be used and documents any tailoring considerations (e.g. tools used to implement the Development Work Plan). The Development Handbook and the Development Work Plan, together, form the basis for managing the project’s development activities and are essential references for all project members and stakeholders, especially for the Agile Project Core Team (A-PCT). Therefore, the Development Handbook is a living document. Any changes or improvements suggested as the outcome of ceremonies like Iteration Retrospectives or Iteration Reviews should be documented there. During the closing phase, the Development Handbook also becomes an essential point of reference for the project-end review meeting and should be properly closed and archived. | Key Participants | Description | |:------------------------- |:----------- | | Team Coordinator (TeCo) | Responsible for drafting the Development Handbook and ensuring alignment with the Project Handbook, in close collaboration with the Project Manager (PM). | | Architecture Owner (ArOw) | Supports the Team Coordinator (TeCo), providing technical advice and identifying technical constraints that may impact the approach to be defined. | | Product Owner (PrOw) | Supports the Team Coordinator (TeCo), providing insight and information related to the requestor’s organisation reality that may impact the approach to be defined. | | Agile Team Member (ATeM) | Supports the Team Coordinator (TeCo), providing additional insights on the tools and techniques that the team plans to use to support the solution’s development. | | [[Project Manager (PM)]] | As accountable, the Project Manager (PM) needs to be aware on how the Agile Project Core Team (A-PCT) plans to manage the development <br> aspect of the project and ensure that the relevant information for the Project Handbook is captured from the Development Handbook. | **Guidelines** - **Use the Project Handbook as starting point** – For a PM2 project, the Project Handbook is a reference and starting point for creating the Development Handbook. Decide if the Development handbook will be an information ==carrier on its own or if it will be embedded in the Project Handbook==. - **Adjust the Project Lifecycle accordingly** - PM2-Agile introduces the CIR (Coordinate, Implement, Review) rhythm. With that, frequent releases, Iterations, ==allow the standard phases boundaries to overlap and be more flexible==. - **Describe the Project Progress Measurement clearly** – Because Agile planning varies in its essence from more traditional approaches, using ==PM2-Agile implies a different way to measure progress as opposed to a standard PM2 project==. This must be described properly, including references to relevant tools like Agile Estimating. - **Pay attention to core Project Process changes** – With PM2-Agile, part of the planning exercise relies on a completely ==different Requirements Management approach== when compared to the standard PM2 methodology. The ==use of stories as the working units that drive progress needs to be clear to all stakeholders==. Furthermore, because Agile foresees “stakeholder collaboration over contract negotiation”, the Change Management process must be adjusted to reflect this agility. Other processes like Resource Management and Communications Management should also be adjusted accordingly. - **Include new PM2-Agile roles and responsibilities** – With PM2-Agile, the Agile Project Core Team (A-PCT) becomes part of the project and with it, ==a new set of roles and responsibilities is added to the PM2 project organisation==. Some of these roles will be closely related with other standard roles, reorganising some of their existing responsibilities. These changes ==must be very clear in the Development Handbook.== - **It’s a living Artefact** – As part of the CIR rhythm, the Review aspect will bring frequent changes to the project’s organics, regardless if it’s process, team or solution related. As such, those changes must be reflected in the Development Handbook. ![[7.2.1 Development Handbook — Inputs and main roles -1 .png]] ![[7.2.1 Development Handbook — Inputs and main roles -2.png]]