^ [[2 About Agile]] # 2.1 Agile Values In 2001, seventeen people brainstormed to find a better way to work, and from that emerged what they called the "**Manifesto for Agile Software Development**". The result of their brainstorming session is published at http://www.agilemanifesto.org/. This content is usually known as the "**Agile Manifesto**" and defines **four values supported by 12 principles**. The **Agile Manifesto provides a foundation for the PM2-Agile framework**. This foundation is **adapted** to reflect its values and the lessons learnt from years of Agile experience, as follows: - The **original** manifesto **focused on software development** – ==PM2-Agile broadens the scope to focus on solution delivery==. - The **original** manifesto **focused on customers** – under ==PM2-Agile, all stakeholders are equally important==. - The **original** manifesto **focused on development teams** – ==PM2-Agile considers the overall organisational ecosystem and how to improve it==. Each of the four values statements in the Agile Manifesto is presented in the format **"X over Y"**. The important thing to understand about the statements is that while you should value the concepts on the right-hand side, you should value the things on the left-hand side even more. A good way to think about the manifesto is that it defines **preferences**, not alternatives, **encouraging a focus on certain areas but not eliminating others**. **==The four Agile Manifesto values are==**: 1. *Individuals and interactions over processes and tools*. 2. *Working solutions over comprehensive documentation*. 3. *Stakeholder collaboration over contract negotiation.* 4. *Responding to change over following a plan.* **First Agile value – individuals and interactions over processes and tools** **Processes and tools** are very useful but they are designed in a particular point in time and based on the knowledge available at that moment. However, because they are implemented and used at a later stage, they are **often unable to accommodate the internal and external changes in projects**. More importantly, work such as software development is based on **people’s knowledge and creativity**. Where **processes and tools** reach their **limits**, **people’s intelligence and ability to collaborate effectively** can provide the necessary responsiveness and problem-solving capacity by generating new ideas and insights from the several different perspectives. As Agile recognises the inherent uncertainty of projects, it values individuals and interactions over and above processes and tools. ==This is one of the key enablers of the Lean UX process, an important pillar of PM2-Agile==. **Second Agile value – working solutions over comprehensive documentation** The time spent documenting is time taken away from developing and learning by presenting prototypes of the project deliverables early in the project. Even if **big part of an iteration deliverable is discarded**, that effort is worthwhile for the feedback gained. And as this **feedback often changes the specifications**, there is all the more reason to **prefer light documentation (or even better light modelling**), because if most of what is specified changes, the specifying effort has been wasted. Moreover, you can often only **discover the true requirements by combining the requesters’ initial ideas** **with** the realisation based on the **developers’ evolving understanding** to produce something tangible, rather than just imagined. Furthermore, stakeholders will have a much **easier time understanding any working solution rather than complex technical diagrams** describing its internal workings or describing an abstraction of its usage. Documentation has its place; deliverable documentation such as **user manuals and operations manuals** are in fact part of the overall solution. The primary goal of any Agile Project Core Team (A-PCT) is to **create solutions, not documents.** That is why it is important to **focus on the core deliverables**. There are three important points to make on this value in an organisational context. - The original Agile Manifesto uses the term "software", not "solutions", for this value statement. Within an Organisation, the word "solutions" is preferred. This is to: - stress that the **software is only one part of an IT project**; - **enable PM2-Agile to be applied to non-IT projects**. - Agile should be applied with the understanding of the core deliverable(s). In cases when Agile is applied to non-IT projects, **it could be that the core deliverable is a document.** In that case, "documentation" should be understood as that type which supports the production of the core deliverables. - There is a **risk of "working solutions" being interpreted in a way that leads to the development of locally optimal solutions**, or "local optima" (rather than globally optimal solutions). ==Therefore, projects that are regarded as successful sometimes contribute to the duplication of IT investments== (building a capability which is available from an existing application) or are designed in such a rigid, closed and non-interoperable way that major additional investment is needed to integrate that application with others. **Third Agile value – stakeholder collaboration over contract negotiation** Contracts are often signed early, leading to burdensome change management procedures. As change is inevitable, it is better to handle it by collaborating effectively with stakeholders. Furthermore, **contracts bring a false sense of security**, while the realisation that the **knowledge of what is required and what has to be done relies on collaboration** to solve the issues and ==take advantage of opportunities not envisaged in the contract==. The **stakeholder collaboration** generates a system of **consensus-based decisions** that allows creating a common and shared understanding of the problem to be solved and the possible solutions. (Note that the original Agile Manifesto used the term "customer" instead of "stakeholder" for this value statement). **Fourth Agile Value – responding to change over following a plan** It is very important to have a plan, but it **should only be detailed for the current iteration**. This will make it possible to **make adaptations based on feedback** received during the current iteration and plan for the next one. Agile practices do allow for **longer-term planning, but these plans should be high-level and created on the understanding that they may need to be updated frequently**. This fourth value, at its core, is the ==key enabler of the Build-Measure-Learn feedback loop== from the Lean Startup model, another important pillar of PM2-Agile. `>` [[2.2 Agile Teams]]