First, let us deal with the mythology. Confusingly, the book Project to Product is not about changing all development activities from projects to products. It is also not about merely renaming the outputs of software development a product, although they might be! The surprisingly named but brilliant book by Mik Kirsten refers to the means of manufacture of the output rather than the output itself. It is about shifting from a single-life, disposable delivery entity (a project) to a flow-oriented, continuous delivery entity (a process). The concept makes many of the planning and control tools and techniques favored by project managers redundant and replaces them with the planning and control techniques used by Lean.
The underlying philosophy addresses the reality that in most modern enterprises, change is no longer “unique in that it is not a routine operation,” to quote the Project Management Institute’s definition of a project, but a relentless continuous necessity. In many contemporary organizations, change has become as much an operational process as sales order processing or purchasing. Recognizing that change or development is incessant allows the mindset to switch from unique project and waterfall to commonplace and process flow orientation.
Treating change delivery as a process has many ramifications for the means of production. With a project, the means — the funding, the people, the tooling, and the facilities — are assembled on a one-off, disposable basis. With a process, the means of production are made available on a continuous, enduring basis. A business in a consumer market would not allocate people to work on a sales order each time such a transaction arrives. Instead, the sales team is dedicated to sales order processing and awaits the arrival of the next customer order. The same principle is now applied to the software delivery process.
Lean calls the process of delivering the goods or services to a customer a value stream. The organization designs and builds a value stream that has capacity, a lead time between order receipt and delivery to the customer, it has people, and it has costs. The process components are aligned to the expected demand; in this case, sales orders, required to be processed by the value stream. The value stream is monitored and measured to ensure that the expectations of the customers and the business are met.
Moving to Product Orientation
So, what are the ramifications of moving from a project orientation to a process or product orientation? First, an organization needs to establish an efficient means of production. It must create a funding model and a value stream equipped and staffed with people able to deliver its software requirements. Then the organization must manage the flow of work into that development value stream. The concept of flow is critical to value stream performance. Lean manufacturing principles have established that an overloaded value stream slows down the rate of delivery, increases costs, and decreases quality.
I have read statements like “every business is a software business” — this, too, is a myth! There is no way my local brewery is a software business, or a car rental company is a software business. To a greater or lesser extent, they are software-enabled businesses. Customers purchase beverages from the brewery, not software! In fact, most businesses do not actually sell software to customers. These organizations use software to engage with customers or support their operations to deliver their products or services to customers. So, are these organizations going to invest, year-over-year, in a single software application? Hardly financially likely or indeed necessary. Most organizations are still going to have endeavors in which they invest for some time to achieve a specific outcome, and some will have an application, like a web portal, in which they may invest continually.
The project to product concept is that these work items, activities with a specific outcome, and projects in the past, are prioritized and flow down the same development value stream. (Most organizations will have value streams comprised of several teams, so work will happen in parallel and not in series as shown in Figure 1.) Importantly, the people stay together and move from one activity to the next.
So how are short-term and longer-term investments in software managed? In many organizations, the project deliveries are monitored by a function called a project management office (PMO). Does a PMO still exist in a product-oriented enterprise? The answer is yes, but to operate, the PMO will need radical reengineering.
The PMO Role
Typically, a function like the PMO manages the development intake process or pipeline, often known as "portfolio management." Portfolio management in most traditional businesses is a process predominantly oriented around prioritization and funding. It is about allocating budget to the endeavor using financial values such as net present value (NPV), internal rate of return (IRR), and time-adjusted rate of return (TARR).
So now we get to the rub, and it is always about the money. If we have established a process to deliver software solutions and that value stream is funded as previously discussed, then the focus of the development intake process switches away from budget to focus on business value creation and capacity. So value — monetary or otherwise — is a critical Agile measure.
Agile activities do not have an estimate. They do not have a detailed requirements stage at the beginning of the project, so they cannot prepare itemized estimates. Instead, an Agile activity is assigned a budget. In the context of moving from project to product, the value stream will be funded, but portfolio management switches to prioritizing the work to be produced.
Agile activities have a high-level scope definition, the detail of which is established as the activity progresses. Yet Agile has a greater emphasis on value creation than do traditional techniques. Agile evaluates the scope of each activity in the context of business increments. In designing the product breakdown, the product owner seeks to maximize the business value of each increment. Using rough sizing measures, the team will evaluate the time or number of sprints needed to deliver the increment. In this way, portfolio management becomes a two-way process. It is no longer a set of requirements with delivery dates given to a team. It is more loading a hopper with work and allowing the process to maximize the value created.
In prioritizing the work to enter a value stream, Agile uses a cost of delay calculation. The cost of delay is an indicator of how much of the business value will ebb away by delaying the increment. Simply put, the cost of delay answers the question: how much value would we lose if we delayed this activity by one month or how much additional benefit would we gain if we brought this delivery forward by one month? The cost of delay forces the sponsors of work to be sure of the business benefit of the request they have made. Special arrangements are sometimes needed for investments where there is no tangible business benefit (such as for regulatory activities).
Figure 1 shows a single value stream. Rather than completing the entire scope of a single initiative, cost of delay would suggest mixing the business increments from different initiatives to deliver the highest value. The same principle is applied across multiple teams and multiple value streams.
Despite what many think, the focus of Agile is not on teams but on the creation of value. It is about maximizing the business value generated over a specific time. So, the primary measures for the PMO moves way from the synthetic data of milestones and RAG indicators to metrics connected directly to the value stream and how much business value has been delivered.
As the objective is to maximize the business value generated over time, the concern is not on starting new activities but on the finishing of business increments. This means that the development intake process must also pay attention to flow and capacity. Why? It is because the wisdom of Lean says that if we push too much work into a delivery pipeline, it gets jammed and everything takes longer.
The focus on finishing work has two ramifications for portfolio management. The process has to have a significant focus on the size of the work items entering the pipeline, and it must have clarity of capacity of the value stream. It is for this reason that Agile has concepts like minimum viable product, which are developed in increments. The implications are that in preparing work for development, due regard must be paid to how the solution delivers business value and how much work is required to deliver that value in viable business increments.
Five metrics measure value stream performance. The first two — flow velocity and flow time — are metrics that relate to the customer. How much revenue was delivered by the value stream and how long the transactions took. The flow operation metric is a ratio that looks at the average transaction cost compared to its revenue. This will show when an organization needs to pivot from unprofitable business or drive operational efficiency. Flow efficiency metrics show where transactions are waiting in the value stream. It allows the team to identify what Eli Goldratt’s Theory of Constraints calls the drum. The drum is the step in the process that constrains the flow in the value stream. Looking at the wait time allows the value stream to be rationalized to deliver value faster. Flow load metrics match transaction load to capacity through the value stream, enabling the analysts to identify opportunities for operational improvements.
So, project to product is a simple statement that has enormous ramifications for project management disciplines. It recognizes that change is continual and, therefore, to reduce waste and increase efficiency, software development and change should be managed as a process. Using a process allows organizational learning, encourages process optimization, and delivers value more quickly. To succeed, there must be an organizational mindset change and a revision of several traditional operational governance processes.
In the next Advisor in this series, we will explore the often-forgotten aspect of Agile: quality. We will look at “shift left” and consider what it really means. We will discuss how the traditional testing V models fit with Agile working and the alternative models that are needed. What are the implications of continuous integration/continuous delivery and in sprint testing on the traditional, often offshore, testing teams?