^ [[2 About Agile]] # 2.3 Continuous Improvement & Validated Learning A core philosophy of Agile is that of continuous improvement and learning. This is done through **frequent reviews and retrospectives**, which are described as rituals where **teams learn from the experience and plan changes for the next cycle**. Reviews are a great tool to collect feedback from the stakeholders and learn about the solution. Retrospectives are a great tool to collect feedback and **learn about the process** and the Agile Team itself. Both are key in delivering a successful project and solution as they will guide the overall improvement process. However, this could not be achieved without effective and meaningful learning. PM2-Agile considers this a cornerstone and embraces the **concept of Validated Learning, a part of the Lean Startup model**, which also plays an important role in PM2-Agile. While the Lessons Learned captured at the end of a project remain valuable, the spirit and **habit** of frequently reviewing and retrospecting must be infused across the project continuum, since this is where continuous improvement and validated learning take place. **Build-Measure-Learn** The teams follow a **feedback loop** to continuously **learn from their hypotheses** and improve by taking advantage of the triggers: the ideas, the product and the data. The Build–Measure–Learn loop emphasizes **speed as a critical ingredient** to continuous and validated learning for proper development afterwards. A team’s effectiveness is determined by its ability to **ideate**, quickly build (**rapid prototype**) a minimum viable product of that idea, **measure** its effectiveness in the market, and **learn from that experiment by analysing the generated data**. In other words, it's a ==learning cycle of turning ideas into products, measuring users' reactions and behaviours against built products, and then deciding whether to persevere or pivot the idea==; this process repeats as many times as necessary. ![[2.3 Minimize total time through the loop.png]] **Minimum viable product (MVP)** Building Start-ups involves many risks and timing. It is safer for start-ups to **experiment** on their **idea** by preparing **early prototypes and test them with their potential clients as early and continuously as possible**. They came up with the idea of an MVP since there was not much time to build something cheap and fast that would allow them to gain learning and lead the market. Building an MVP doesn’t necessarily mean that a fully functional piece of coded software needs to be developed. The **most important aspect is that the usage of the MVP can be measured and the data collected is used to learn and generate new ideas**. This is what will keep the cycle going and consequently, make the solution grow towards the right solution. **The Lean UX process** (another cornerstone of PM2-Agile) **goes hand in hand with the Lean start-up model by helping to generate the MVP with rapid prototyping and gain fast learning**. The Lean start-up model and Lean UX process have been implemented also by the public sector worldwide to reduce the uncertainty of costs and risks at later stages of product development, where many stakeholders and governmental budgets are involved. The Minimum Viable Product (MVP), is the result of continuous validated learning that gives the **green light for Incremental Development or even an indication of a non-continuity of an idea**. ![[2.3 What an MVP is and what it is not.png]] **The Purpose of an MVP** - Be able to **test a product hypothesis with minimal resources**. - **Accelerate learning**. - **Reduce wasted** engineering **hours**. - Get the product **to early customers as soon as possible** to learn from its use. - **Base for other products**. The figure below shows all the key elements that must be considered to build the right product with fewer risks and be ready for the market. It is highly recommended to **incorporate all those elements** instead of shortcutting and focus on just one or two. ![[2.3 The right MVP - all key elements are met.png]] An **MVP** must include and **focus on the following key elements**: - **Functionality**: the set of features must deliver/demonstrate clear value to the user. - **Accessibility**: the MVP must comply with accessibility standards. - **Reliability**: the adequate evidence that confirms that the initial problem or goal is solved in a manner that it is **coherent and relevant** to move forward. - **Design**: the design of the MVP must be up to the highest industry standards. - **Usability**: the MVP must be easy to use and intuitive. - **Value**: the MVP brings organisational value and serves **user needs**. **Success criteria** - Comply with all **key elements**. - Define from the beginning **key performance indicators (KPIs) and metrics**. - Conduct **frequent user research** with users and **validate with stakeholders**. Try to keep up the research ==up to five users to avoid wasted time with over-analysis==. Next: [[2.4 Agile Myths]]