Chapter 8: Lean Development Life Cycle

The project development life cycle is a set of sequential phases needed to develop (create) the project's assets.

Development Life Cycle Models

According to the current understanding, there are five models of project development life cycle [1]:

• Predictive (plan-driven)
• Iterative
• Incremental
• Adaptive (agile)
• Hybrid

Traditionally, it’s considered that predictive, adaptive and hybrid life cycles have relative advantages and disadvantages and that each of them may be the best choice depending on the specific project context.

Predictive Life Cycle

This cycle, commonly known as waterfall method or approach, comprises successive phases, for example analysis, design, development, testing and implementation. To start any phase, the team must complete the previous one. There is a specialization of tasks within each phase. The team transfers all intermediate deliverables from one phase to another and makes a single delivery at the end of the project. They create detailed requirements and plans upfront and strictly control changes. This is a linear approach for executing in a single pass.

This approach is also called "sequential", which we think is a better name because "predictive" does not provide information about the phases of the cycle and can mislead as to the predictability of the outcomes.

Iterative Life Cycle

Iteration means repetition. To iterate means to repeat something until a certain condition is met. The iterative life cycle repeats the development phases (e.g., analysis, design, development and testing) several times improving the deliverable until we meet the completion criteria.

This approach is feasible for creating information-based assets and is generally not suitable for physical deliverables (e.g., a building). Physical deliverables, however, have intermediate information-based products to which the iterative approach applies. For a building, for example, there are architectural and structural drawings, specifications, construction plans, etc. In a broader context, developing models and prototypes is also an iterative approach that applies to any type of project deliverable.

Incremental Life Cycle

Increment means increase. Development starts with implementing a subset of the deliverable functionality (an increment). The team gets a feedback from the development process and from the customer and creates successive versions of the deliverable (increments). The goal is to make each successive increment better and more functional.

Adaptive (Agile) Life Cycle

While each cycle involving an iterative or incremental approach is adaptive (also called evolutionary), the agile development cycle is both iterative and incremental.

A hybrid life cycle combines both predictive and adaptive life cycles.

The Development Life Cycle of LeanPM

The Lean philosophy is evolutionary and many lean practices are iterative and incremental.

Iterative and incremental cycles have been successfully applied in the lean product development and lean startup contexts.

Regarding the sequential (waterfall) life cycle, we need to answer the following questions:

1. Is the evolutionary approach always applicable or sometimes it’s just the sequential one?
2. Does the sequential approach have comparative advantages over the evolutionary approach?

Applicability of the Evolutionary Life Cycle

Every human activity is incremental and iterative.

For example, making a pot out of clay involves several steps by which the pot gradually acquires shape, volume and functional qualities. If necessary, the potter goes back to the previous steps and remakes the pot, or if it was already baked, remakes it to achieve the desired outcome.

After making one pot, the potter strives to make each subsequent pot better. The thousand-year-old evolution of pottery results from an enormous number of pot increments and iterations.

Unlike pottery, the evolutionary nature of human actions isn’t always visible. For instance, large-scale manufacturing creates the illusion of linearity in which the product moves in one direction only, and thousands of products do that day after day, in exactly the same way. However, Lean reveals the natural iterative and incremental nature of manufacturing, just like the potter's work, and uses this to improve performance.

Does this apply to projects? Manufacturing is an environment with very little uncertainty. By definition, projects are subject to greater uncertainty than a production line, but if work on a project is predictable and certain, it’s better to perform it as an ongoing operation. Therefore, even a project with a very low uncertainty has higher uncertainty than ongoing work such as manufacturing or service operations. What applies in terms of the iterative and incremental approaches to manufacturing is even more applicable to projects.

Have any of us taken part in at least one project that was executed in a strictly linear way, from start to finish? The answer depends on the definition of linearity, but from a purely practical point of view, this is rarely possible or even desirable. In most cases, the linearity of the sequential life cycle, just like its predictability, is an illusion. It gives us a false sense of security and prevents us from reaping the benefits of the evolutionary approach.

We don't have to go far to find many projects with sequential development cycles that incorporate change, refinement and rework cycles, and overlapping phases which indicates evolutionary development. As Don Reinertsen points out, when product developers are obliged to follow a sequential life cycle, rational behavior prevails and most of them informally overlap development phases [2].

Evolutionary development is always feasible, and also generally occurs in projects with a sequential development cycle, taking the form of unplanned, unwanted, or even forced evolution. Not every project is able to deliver working products at the end of subsequent iterations, but almost every project can demonstrate increments of intermediate deliverables or models.

Does the Sequential Life Cycle Have Advantages?

Among the perceived advantages of the waterfall model are:

• Departmental efficiency
• A logical and intuitive framework
• Minimum customer feedback is needed
• Easy to measure progress
• Easy to manage because the phases are being worked on one at a time and have specific deliverables and review processes
• Better time and cost control because of the detailed upfront planning
• Clear requirements that largely remain unchanged

The departmental efficiency has no impact on the profitability of the project, so this metric is irrelevant.

Logic and intuitiveness are socially determined. Many lean concepts are counter-intuitive, but only because we are taught to think differently. As we find better ways, our understanding and perceptions change. After all, we should judge an approach on the results, no matter how logical and intuitive it may be.

Many of the perceived advantages are not just because of the application of a sequential life cycle, but because of the low uncertainty inherent in certain projects. These are the benefits of clear requirements, better planning and control, and the minimum need for feedback. It's a vicious circle. On the one hand, some argue that the sequential approach is appropriate when there is low uncertainty and, on the other, that the advantages of the approach stem from the low uncertainty.

Is it easier to measure progress with a sequential development approach? Good metrics must show that the project is making progress in producing a net benefit. Some argue that the existence of a detailed plan and well-defined milestones facilitate monitoring and corrective actions. However, in this case progress is measured against the plan rather than towards objectives. Actually, the sequential approach is the least suitable for measuring progress, since it’s only at the end of the project that we have finished deliverables that we hand over to the customer.

This model has one possible advantage that is rarely mentioned. The number of transfers from one work process to another is limited by the number of development phases, which translates into lower total transfer (transaction) costs. We should note the following regarding this perceived advantage:

• Typically, the actual number of transfers is greater than planned, because of unplanned changes and rework.
• Transaction costs alone are not a good measure. We need to find an optimal trade-off between the transaction costs and benefits and we don't achieve this optimum when there is only a small number of transfers.
• We can reduce the cost of individual transactions and increase the number of transactions (we look at this in the following chapters).

In summary, this advantage is relative and conditional and cannot justify the use of the sequential life cycle. 

The LeanPM Development Life Cycle Approach

In the last sections above, we answered two questions:

1. Is the evolutionary approach always applicable or sometimes it’s just the sequential one?
2. Does the sequential approach have comparative advantages over the evolutionary approach?

From the answers to these questions, we can conclude that the evolutionary life cycle approach is always feasible and even natural, and the sequential (waterfall) approach has no advantages over it.

The LeanPM development life cycle is based on an evolutionary approach. It has the following core features common for all its variations:

• Customer pull
• Workflow management and optimization
• Incremental and (when feasible) iterative creation
• Small batches of work and fast feedback loops
• Overlapping development (creation) phases
• Integrated, cross-functional and self-organizing teams (Lean-Agile teams)
• Plan, Do, Check and Act cadences
• Synchronized creation and absorption

In a project management context, cadence is the rhythmic sequence of activities performed at regular time intervals. Regular cadence helps lower transaction costs, limit the accumulation of variance, make waiting times predictable and enable small batch sizes. Examples of time-based cadences are regular project meetings, prototyping, testing, reviews. [3]

Periodic planning (e.g., weekly commitment planning), fixed-length iterations and work time-boxes (e.g., weekly or daily work) are also examples of cadences. In general, we’ll talk about Plan, Do, Check and Act cadences.

The regularity of cadences should be based on domain, circumstances and coordination and transaction costs and can be empirically adjusted. [4] 

The absorption starts before and ends after creation of deliverables, but these two types of activities need to be performed as a single value stream. Absorption should not be pushed by creation, nor should just mirror it. Absorption must be pulled by the customer and synchronized with their capacity and needs. And then absorption will pull creation. An initial Setup stage is another common feature of all lean development life cycles (Agile developers may prefer to call this stage “Iteration 0”). It’s a short pre-work stage that may involve:

• Establish and train project team
• Organize team work space
• Establish team ground rules, culture principles, processes and logistics
• Set up tools and technical environment
• Develop stakeholders’ Conditions of Satisfaction
• Define project vision
• Refine project milestone/master plan and/or develop product vision and create initial product backlog

Outside the common features, the major differences between the life cycle models are dictated by the possibility or impossibility of applying an iterative approach. Projects in which this is possible should, as a general rule, apply an iterative development life cycle. Examples include knowledge work projects like product development, research, design, software development, process improvement, etc. Iterations are usually not feasible in production projects like construction. We should consider mixed approaches, too. For instance, a design-build project can use an iterative life cycle for the design and non-iterative for the construction.

The major building block of the iterative life cycle is the iteration – a timeboxed PDCA work unit aimed at creating an increment of potentially absorbable project assets. When absorbed into the customer’s value stream, we expect the increment to generate incremental value.

Let’s exemplify the iteration with the Sprint of the Scrum framework [5]. Sprint is a time-box of no more than one month, during which the team creates a valuable and usable Increment (or multiple Increments) with minimal external interference. The Sprint length – the heartbeat of development – is fixed for all recurring Sprints. According to Scrum, we can see each Sprint as a project with a goal to build something, a plan, work and an outcome – product increment.

Sprints comprise five components:

1) Sprint Planning

This is a time-boxed collaborative work to plan the upcoming Sprint. Sprint Planning answers what can be delivered in the upcoming Sprint and how will the work be performed.

Key input to Sprint Planning is the Product Backlog, which is a list of all product features, functions, requirements, enhancements and fixes that will be worked on (Product Backlog items). Each item is defined in terms of description, order (priority), estimate and value.

The team selects Product Backlog items for the Sprint within their capacity and plans how to deliver them. The Sprint Goal, the selected items, and the delivery plan form the Sprint Backlog. The team also defines a Sprint Goal – the objective that will be achieved during the Sprint – which informs team why the product Increment is valuable to stakeholders.

2) Daily Scrums

The Daily Scrum is a very short inspect and adapt meeting of the team to inspect progress, track the total work remaining, and plan the work for the next 24 hours. Daily Scrums improve a team’s communication, knowledge and decision-making, and identify impediments. Often, this meeting is followed by a detailed discussion or by adapting or replanning the Sprint’s remaining work.

3) Development work

The self-managing and cross-functional team performs the work of the Sprint and inspects the resulting increment and the progress towards the Sprint Goal. The team aims at delivering a working Increment of the “Done” product at the end of the Sprint. If the team detects undesirable deviations, they make a quick adjustment. The development team tests each Increment and ensures that all Increments work together.

4) Sprint Review

The Sprint Review is an informal review meeting of the team and key stakeholders at the end of the Sprint. The purpose is to inspect the “Done” Increment and, if necessary, to adapt the Product Backlog.

The team demonstrates the Increment and discusses the work completed during the Sprint – what went well, what were the problems and how they solved them. The participants discuss what to do next in order to provide input into the following Sprint Planning. They review time, cost, capability and market aspects of the next product releases.

5) Sprint Retrospective

This is a team meeting held between the Sprint Review and the next Sprint Planning that focuses on team’s inspection and adaptation. The team inspects the last Sprint and identifies improvements regarding people, relationships, process and tools. Then, they create a plan for improvements that they will implement in the next Sprint (adaptation to the inspection). Also, the team plans how to improve product quality by enhancing work processes or the definition of “Done”.

Cadences

The Scrum framework doesn’t mention cadences, but uses them. Here are the PDCA cadences of Scrum:

• Iteration cadence. These are the fixed-length Sprints that follow immediately one after the other. The Sprint encompasses all other cadences. There are two groups of plan-do-check-act Sprint activities that have a daily and once-per-Sprint rhythm. As there is a limit to the maximum duration of the planning, review and retrospective activities, the Sprint length and the start date of the first Sprint determine the duration and the timing of the other cadence activities.
• Plan cadences are Sprint Planning and the daily planning and coordination performed in Daily Scrums.
• Do cadences are the development work component of the Sprint and its daily work subsets enabled by the Daily Scrums.
• Check and Act (Inspect and adapt) or Improvement cadences include Sprint Review, Sprint Retrospective, and Daily Scrums as formal opportunities for improvement.

Figure 8.1: Iterative Life Cycle

In the iterative life cycle (and in any other evolutionary life cycle), Absorption and Creation must be synchronized and planned together, but they may have different work cadences.

LeanPM Exploratory (Lean Startup) life cycle is a variation of the Iterative life cycle. It’s based on Eric Ries’s Lean Startup ideas [6]. This life cycle can create value stream assets and generate validated learning under uncertainty, while reducing risk and waste and increasing value.

The essence of the Exploratory cycle is creation through experiments in successive iterations and tight feedback loops. The idea of a new asset (new product, service, value stream, model, technology, method, strategy, growth engine, etc.) can be based on assumptions about its functionality, feasibility and viability.  We must turn these assumptions into hypotheses that need to be tested using a Minimum Viable Asset (MVA, which is a more general term that extends the widely used term "Minimum Viable Product").

The Minimum Viable Asset is a version of an asset that enables the gathering of as much information as possible about the hypotheses, with as little effort as possible. This information is analyzed to generate validated learning about the asset. A plan-do-check-act cycle is run and one of the following decisions is taken in the Act phase:

• Persevere – stay the course and continue improvements and tests
• Pivot – make a major change to test a new fundamental hypothesis [7]
• Stop the work because the required knowledge has been acquired or the desired asset created 
• Abandon the idea, as an important hypothesis about its viability or feasibility has been invalidated

Figure 8.2: Exploratory (Lean Startup) Life Cycle

The evolutionary nature of the Non-iterative Life Cycle is ensured by the realization of the key characteristics we’ve identified above, otherwise, this would be a Waterfall life cycle. The project milestone plan can serve as a starting point for this life cycle. Although not of uniform duration, the stages defined by the main milestones represent the general cadence framework in which the PDCA cadences fit. Note that stages (management phases) don’t overlap, unlike the technical phases of development (creation).

Here is an example of PDCA cadences for this cycle:

• Plan cadences: stage planning, lookahead planning for the next 4-6 weeks, weekly commitment planning and daily planning facilitated by daily team meetings
• Do cadences: weekly work cadence enabled by commitment plans and daily work cadence enabled by the planning and coordination activities of the daily meetings
• Check and Act cadences: stage review and retrospective, weekly inspect and adapt cadence for the work performed in the past week, and daily inspect and adapt cadence facilitated by daily meetings

Figure 8.3: Non-iterative Evolutionary Life Cycle

We can use the Continuous Delivery Life Cycle for both iterative and non-iterative creation and absorption. It has a complete set of PDCA cadences, which, however, are not placed in a common container such as an iteration or stage. The work is pulled from a single backlog when resources become available or following a pull signal which is linked to Work in Progress limits. This cycle is appropriate when work items are similar in size and scope and the work is performed by stable long-term teams.

In the iterative cycle, the time-boxed iteration largely determines the cadences and limits their flexibility. For instance, the iteration time-box does not allow re-prioritization of work items before the next iteration, even if requirements change often. In the continuous delivery life cycle, the cadences depend on natural needs to maintain flow. Each PDCA cadence is allowed to adjust and differ from other cadences, including planning, prioritization, input queue replenishment, development, coordination, delivery, release and review cadences. [8]

For instance, the Kanban method, which uses a continuous delivery life cycle, has seven feedback cadences (some of them are at portfolio level) [9]:

• Strategy Review (quarterly)
• Operations Review (monthly)
• Risk Review (monthly)
• Service Delivery Review (bi-weekly)
• Replenishment Meeting (weekly)
• The Kanban Meeting – daily coordination, self-organization, and planning review (daily)
• Delivery Planning Meeting (per delivery cadence)

The Continuous Delivery Life Cycle works best when it’s possible to create and absorb valuable project deliverables regularly. Such are the cases with implementing a series of short regular projects and with projects that regularly create absorbable increments.

Not every project (even not every software development project) can create a regular flow of valuable deliverables. Often, we have to create a certain configuration of deliverables or the whole configuration of project deliverables in order to have something of value for the customer. For example, a completed bridge section has no usable value for the customer until and if we complete the entire bridge. The “earned value” of the completed section is conditional and uncertain. In such a case, we can't talk about continuous delivery.

Uncertainty and the Lean Development Life Cycle

The way we should apply the LeanPM development life cycle approach depends on the level of uncertainty.

Uncertainty arises from a lack of knowledge or from our inability to predict future events (unpredictability). There are two types of project-related uncertainties.

We associate parameter uncertainty with variations in the input values used in the project success model, that is the cost-benefit analysis model. These are the values of the various components of the project's benefits and costs, and the parameters that affect them, such as revenue, time, scope, quality, effort and team productivity.

Model uncertainty affects two project models. The first one is the model of cost-benefit analysis. The main issue here is the uncertainty about the trade-off relationships between the parameters of the model. 

The second one is the model of the project logic. There is an uncertainty in the causal relationships between the project's logical elements. These relationships are a hypothesis of change and achievement of net benefits, based on assumptions and affected by risks. In fact, the uncertain logic leads to parameter uncertainty. But this uncertainty also signals potential significant project waste, including strategic waste.

Uncertainty may have both positive or negative effects on the project. 

Uncertainty exists due to lack of knowledge and due to variation. The prime factors influencing project uncertainty due to variation are:

1. Variability of requirements and the development process 
2. Variability of the project environment
3. Variability of resource supply and demand
4. Project complexity

Let’s review each of these four factors.

1) Variability of Requirements and the Development Process

This is not about setting restrictions on changing requirements and the development process, but about the probability of such a need to arise. If we use a well-tested and proven benefit creation model in a stable environment, and if our experience with similar projects allows us to determine the values of the success model parameters with high accuracy, there will be little need for change.

An example would be projects that replicate existing value streams. One such project would be the construction of an electrical substation of standard design based on our experience of building many similar substations. Another example could be an event project as part of a series of similar events from which we have gained considerable experience. By contrast, an innovative project of an unknown nature may have high variability in the requirements and development process.

2) Variability of the Project Environment

The uncertainties of the project's organizational, market, legal, social and physical environment may vary widely. The demand for a project product, or the cultural-driven reactions of stakeholders, are some of the many possible variables.

3) Variability of Supply and Demand

Both demand and supply of resources can change dynamically during the project execution, making it more difficult to align them at any given time.

4) Project Complexity

According to the Association for Project Management, a complex project may involve [10]:

• Many interrelated subsystems or sub-projects 
• Interaction with several organizations or units
• Several phases which may overlap
• Several different disciplines
• A need for a wide range of project management methods, tools and techniques

As complexity increases, it becomes more difficult to model a project’s behavior due to the increasing number of interactions both within the project and between the project and the environment. Complexity increases project model and parameter uncertainty.

Projects take up the entire spectrum of the uncertainty continuum. At one end are the low-uncertainty projects (availability of knowledge; low requirements, process and environment variability; low resource supply and demand variability; low project complexity) and at the other end are the high-uncertainty projects (lack of knowledge; high requirements, process and environment variability; high resource supply and demand variability; high project complexity). Most projects fall between the two extremes.

Although all projects should use iterative (when feasible) and incremental creation process with small butch sizes of work items and frequent feedback loops, uncertainty affects how we should apply this evolutionary approach. 

Project characteristics that uncertainty affects are:

• Reliability of upfront planning 
• Required size of small batches of work
• Required frequency of feedback loops
• Required number of iterations
• Need for hypotheses testing and validation
• Planned capacity utilization

Figure 8.4: Uncertainty and Project Characteristics

What we show in the figure are guidelines. We will look at the project development cycle in more detail in the Managing Creation and Absorption chapter.

Takeaways: Lean Development Life Cycle

• It’s traditionally believed that predictive (waterfall), adaptive and hybrid life cycles have relative advantages and disadvantages, which makes each of them the best choice in a specific project context.
• However, all human activities are incremental and iterative, adaptive and evolutionary, and projects are not an exception. The evolutionary approach to project development processes always applies, and the sequential (waterfall) approach doesn’t have advantages over it.
• The LeanPM Framework uses an evolutionary development life cycle which is incremental, iterative (when feasible) and entails customer pull, overlapping development phases, small batch sizes of work items and fast feedback loops, workflow management and optimization, Lean-Agile teams, PDCA cadences, and synchronized creation and absorption.
• Variations of the evolutionary development life cycle are the Iterative Life Cycle, Exploratory (Lean Startup) Life Cycle, Non-iterative Live Cycle, and Continuous Delivery Life Cycle.
• The evolutionary development approach should be tailored to the level of project uncertainty regarding the planning process, the size of the small batches of work items, the frequency of the feedback loops, the required number of iterations, the need for hypotheses testing and validation, and the capacity utilization limit.
• The two types of project-related uncertainty are parameter uncertainty - the variability of the project’s costs and benefits components, and model uncertainty - the uncertainty about the causal relationships between the project's logical elements and about the trade-off relationships between the parameters of the cost-benefit model.
• The key factors in project uncertainty are the lack of knowledge, the variability of the requirements and the development process, the variability of the project environment, the variability of the resource supply and demand, and project complexity.

_______________

[1] A Guide to the Project Management Body of Knowledge (PMBOK Guide), Sixth edition (2017). Project Management Institute 

[2] Reinertsen, Donald G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing 

[3] Ibid.

[4] Anderson, David J. (2010) Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, WA: Blue Hole Press

[5] Ken Schwaber & Jeff Sutherland. The Scrum Guide, 2017 and The Scrum Guide, November 2020 

[6] Ries, Eric (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Currency

[7] Ibid.

[8] Anderson, David J. (2010) Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, WA: Blue Hole Press

[9] Anderson, David J. and Andy Carmichael PhD, FBCS. Essential Kanban Condensed. First digital version, 17 April, 2016. Referenced version 28 July 2016. Available for download via leankanban.com/guide.

[10] Association for Project Management Registered Project Professional – RPP Competences  (2015). Association for Project Management (apm.org.uk/media/4187/rpp-competences.pdf) (last accessed 2022-10-20)