# The Project to Product with Scrum Playbook ## A AME3 Decision-Making Guide for Project-Centric Organizations The demands for agility in projects are increasing more and more because the surrounding conditions such as customer requirements, technological progress and society are changing at ever shorter intervals. [[Scrum]] has therefore become an essential part of everyday project work in companies. It is not unusual for a project to require several teams and Large Scale Scrum ([[LeSS]]) is the consequent choice here. However, project-centric organizations often waste potential and resources when they try to combine projects with long therm product and service development. The guideline presented here helps to make decisions at the right time whether and how [[Scrum]] or even [[LeSS]] should be used for projects in the organization. In doing so, the advantages resulting from the product mindset of Scrum can be better utilized. By following the playbook, the first steps are made to move the project portfolio forward to a decision-making instrument for investing in innovation and improving the enterprise’s value creation. We simply call that [[Enterprise Backlog]]. Furthermore, an [[Arena]] will continue in advancing the [[Arena Product|Product]]. This is a starting point for an evolution-based organization design based on [[AME3]]. Alternatively, money has been saved because the project was stopped as soon as the early results indicated that the promised ROI would not be achieved. ![[The Project to Product with Scrum Playbook.png]] _All junctions of the playbook are shown in the following image. Detailed description of each junction and routs can be found in the following article by its number._ > [!button] [[The Project to Product with Scrum Playbook.pdf|Download as PDF]] ## Project vs. Product > „A project is a temporary endeavor undertaken to create a unique product, service, or result.“ This is the definition of a project according to the Project Management Institute (PMI). A project therefore has a fixed time frame in which investments are made to achieve a result, e.g. an improvement in the production process or a software system. This is a significant difference to a product. The lifetime of a product is not fixed. In fact, we as a company are constantly investing in the product. Primarily with the work of our employees. Even if we want to get rid of the product once, we have to invest. It is ultimately the last user of the product who determines when a product no longer exists. Perhaps the employee of a waste disposal company. Products are therefore significantly larger in scope than projects and the targeted performance is anything but linear and also difficult to predict.  The blue curve in the image should be considered as the desired development of the ROI. From a company’s perspective, a project is an investment in the product for a certain period of time (red box in the image). Scrum is a framework that is helping to optimize the value generated for this investment. Scrum can be understood as a sequence of projects with a fixed period of one sprint (green boxes in the image). Scrum thus generates knowledge about how the next investment in the product can be improved at often much shorter intervals as before. In extreme cases, this knowledge can stop the investment in the product completely at an early stage. So, how should you handle a new project if you want to think in terms of product development right from the start? ## Junction #1: Simple, Complicated or Complex? ### (1.1) Short Project Duration, Complicated Undertaking. In many companies, there are projects that are smaller than a [[Sprint]]. This means that they are completed within 4 weeks or less. For example, the customer projects of a web agency. Setting up a separate Scrum team for each of these projects, or rather customer orders, would take too much time and effort to build up the team. Instead, it is advisable to include the customer order as a Product Backlog item and a Scrum team pulls the item in one of the next sprints. The team can then optimize its work with the customer so that waiting times are minimized and a customer order can be completed within a sprint. This increases value and flexibility for both the customer and the web agency. Some of the web agency’s client assignments may stretch over 2–3 sprints. Nevertheless, the amount of work is relatively small and well understood. However, there are always waiting periods because decisions have not yet been made by the customer, the customer’s work packages have not yet been completed or things are only to be delivered on a certain date. The picture below shows the customer projects of a software company on a Kanban system. The backlog entries for training by the support team, customization of the standard software by the software team and provisioning of the infrastructure were created by the team members and ranked accordingly in the Backlogs.  (1.2) At this stage, you may not have a real Scrum team in the company at all. To start with, you should first ask, what is the product that the employees are working on? To find an answer, it helps to look at the meaning of the term “product”: > “The product is the result of work”. In the case of the web agency, the product could therefore be: “The Service for the development of web offerings”. The scope or limits of the product must therefore be set particularly broadly. If so, a Scrum team can be formed to improve and deliver the service. It is then also clear that in the case of the web agency, the Scrum Product Owner role is provided by the web agency itself and not by the customers. This is because the agency owns the service and bears the associated obligations. An essential task of the Product Owner role is to evaluate the customer orders according to an internal customer ranking and to position them in the Product Backlog. Even if each item is only complicated, operating and improving this service as a whole can be very complex. There are projects whose context is very well understood and are constantly in the complicated or simple domain. For example, the customer projects of a prefabricated house manufacturer. Here, they rely on serial production to reduce unit costs and to scale in the market. The fewer variants you allow in the houses, as less complicated the work system will be. And the greater is the potential for mass scaling, of course. The team or teams primarily consider the result of the production and construction as their product. In other words, the turnkey houses. They derive the necessary optimizations from the experience gained from the customer projects and take these into account in their Product Backlog. To do this, planners, manufacturers, fitters and craftsmen in the teams break down these improvements into suitable Product Backlog items together. For example, one team can advance the further development of the smart home control system, while another team deals with the automation of series production and a third team takes care of the semi-automated order and planning process. I recommend using [Wardley Maps](https://medium.com/wardleymaps) by [Simon Wardley](https://medium.com/u/8aec33a1b502) to identify multi team structure and potential for innovation. > [!info] In [[AME3]] small projects are most likely one or a set of [[Improvement|Improvements]] in the [[Arena Backlog]] ### (1.3) Complexity and Need for Innovation is High The majority of projects in companies usually have a significantly longer duration than 2–3 sprints. A longer duration is an indicator of higher complexity. Complex means that many unknown factors will influence the project that cannot be predicted at the start of the project. This is not a failure of the project team, but is simply the nature of projects and product development. One factor is the constantly changing requirements. Another is technical realization because many solutions are uncharted territory. Very innovative projects are characterized by the fact that we only work with very vague assumptions for both factors. We can’t even say how many changes we will have and in what quality. It is in the nature of things that it is difficult to determine the degree of complexity. As a simple guiding principle, we can state: If the question whether the project is complicated or complex needs to be discussed. Then it is most likely complex. Howerver, David Snowden’s [[Cynefin|Cynefin Framework]] can provide guidance here. > [!Info] In [[AME3]] a complex project is seen as a [[Goal]] ## Junction #2: Does the WIP Limit for Active Projects Allow You to Start a New Project? So far, we have brought the project to the team or teams. The advantage is obvious. We don’t have to invest in setting up a new team. The employees are also grateful because they don’t have to constantly reorganize themselves and can focus on results. The work more likely in a flow state, and we are talking about real, effective teams. However, if our project is complex and our demand for innovation is high, we come to the standard case for Scrum. This is actually the birth of every Scrum environment, as described in [[The New New Product Development Game]] by Ikujiro Nonaka and Hirotaka Takeuchi. We look for the right talents to form an initial, new team. A Scrum Master or [[System Lead]] takes care of building the team. A manager with decision-making powers takes on the role of Scrum Product Owner or [[Owner]]. This team, which is as autonomous as possible, can now question existing rules and develop entirely new approaches to solving the problem. To a certain extent, we can see such a team as a start-up within the company. Some companies even go down the path of funding a real start-up. (2.1) But beware, many companies fall into a trap here. Too many projects are started at the same time. There are companies whose number of active projects is greater than the number of employees. A complex project does not just affect one team. Often several teams are involved and the work of the entire organization is influenced. The project team or teams are therefore anything but autonomous. It is difficult to predict how many parallel projects a company can carry out without causing a traffic jam or a complete blockage in the work system. However, it is safe to say: fewer than one might first assume. The fewer the number of active projects, the higher the lead time. This generates value and feedback earlier, which in turn benefits the next projects. (2.2) So before starting the next project team — with or without Scrum — it is essential to check that the maximum reasonable number of active projects is not exceeded. If this is true, the project must be weighted against all other projects. Are those organized with Scrum, then the [[Increment]] and the experience of the team(s) is providing the best possible data for the decision makers. A positive result of this step can therefore be, to cancel an active project in favour of a new, more attractive project. It makes no sense to throw good money after a bad investment. Finally, a project can be considered as an entry in the company's project backlog. In [[AME3]] simply named [[Enterprise Backlog]]. Many companies often no longer use the term project at this level. Personally, I prefer the term innovation [[Goal]]. Because that’s what we want to do. We intend to innovate with our product and set ourselves a goal. In any case, a project profile that outlines the most important parameters is sufficient. With the [[Goal|Goals]] or project profiles as entries, the [[Enterprise Backlog]] can be the input for a [[Kanban]] system to make the flow from concept to cash transparent. With such a system, you can now explore how high the maximum parallel project load can be, by experimenting with a work-in-progress limit (WIP-limit) for [[Goal|Goals]] or projects. The picture below shows such a Kanban system after an initial workshop. It shows all known projects in the pipeline. Some projects have a volume of more than 10 million € and an estimated project duration of more than 2 years. However, the option column is not yet an [[Enterprise Backlog]]. This is because most projects of the [[Enterprise]] are missing. It only displays the projects that the potential new [[Arena]] will likely be influenced by in the future. Well, at least the workshop participants quickly agreed that the pipeline is already jammed.  > [!info] In [[AME3]] the list of all [[Goal|Goals]] (projects) are named [[Enterprise Backlog]], prioritized by the [[Enterprise Owner]]. Only the [[Owner]] of an [[Arena]] can pull a [[Goal]] into focus. ## Junction #3: Continue the Project as Product Development  (3.1) With the description _Desired ROI development of the product_ for the blue curve in the picture, you can already guess. The reality will probably be different. Whatever the innovation project or [[Goal]] was, the costs are most likely higher than expected. Scrum is now showing its full strength because in accordance with the principles of the [[Manifesto for Agile Software Development|agile manifesto]], progress is measured by the finished product [[Increment]]. It is the best source of data for making predictions about the future. You get more information with every sprint. Usually after 3 sprints, at the latest after 9 sprints, a decision can be made whether to continue with the product development. It is crucial to consider now the following: 1. Stabilize the team and do not expand it unnecessarily. Far too often, a new employee is hired for every new problem. It is more important to keep the social complexity for the team members to a minimum. Perhaps external staff have been brought in and you should now secure the talent on a permanent basis. The project team may become a new organizational unit. 2. The product owner should pay particular attention to the non-functional requirements or aspects of the product and focus the team on technical excellence and a solid system architecture. More important than scaling employees in the working system is being able to scale the product in the market. For example, should the teams be able to prove through experiments how they intend to ensure the exponential user growth the product is aiming for? Or what architecture is needed to be able to constantly deliver new features? 3. If the product team grows to more than 10–12 people, the ScrumMaster should choose a lean framework for scaling. If done skillfully, scaling according to [[LeSS]] will happen by itself. For example, by following the principle “LeSS is multi team Scrum”. (3.2) As previously mentioned. A win can be the early conclusion that the new product and thus the project will not be a success as expected. Now it becomes clear how essential it is to have a Product Owner who actually takes ownership. She must ensure that the strategy on the flight level of the project and innovation [[Goal|Goals]] is changing. This clears the way for a project that can open up more opportunities for the company.  In case A, you will probably continue to invest in the product. In case B, you will most likely cancel the project and product development. > [!info] In [[AME3]], the [[Owner]] and [[Enterprise Owner]] are responsible for deciding whether to continue working on a project ([[Goal]]) or to change direction by removing the current [[Goal]] and focusing on a new one. ## Outlook: Switching to an AME3 Arena > [!info] Following the playbook here, an [[Arena]] in the sense of [[AME3]] has already been established. Now that the project has produced a promising result and a new, Scrum-based working system has been piloted, the question arises as to if and how we can use this for the entire organization. (4.1) It may be possible for our newly created project organization to work very independently of all other parts of the organization. There is much to be said for leaving the organizational unit as such. We call that unit [[Arena]] in [[AME3]]. > [!info] [[AME3]] leverages established frameworks and methods. However, employing Scrum or LeSS is merely a suggestion. For example, an [[Arena]] may include organizational components within the complicated domain that are not suited for optimization through Scrum or LeSS. (4.2) If other teams are also working on the same or related products, it makes more sense to use the new expertise and incorporate it into an overall product organization, a.k.a [[Arena]]. Of course, this means a reorganization of the teams and the organizational units involved. In the end, the sub-product created initially by the project is further developed by all teams of an [[Arena]]. Such an organization then no longer speaks of projects but, as mentioned above, of [[Goal|Goals]]. ![[Product enters Stabilization.png]] This is particularly advantageous when the further development of the Product enters the stabilization phase. In other words, we only have an interest in ensuring that customers can continue to generate value, but we do not expect innovation and therefore massive value growth. The [[Accountable Representative]] of an [[Enterprise]] should now refine the strategy toward the next step in the evolution of the product and services. The result will be new [[Goal|Goals]] for innovation. An [[Arena]] can pull that [[Goal]] and a [[Team]] start working on it using [[Scrum]]. <!-- AME3 Naming Checked by LLM-->