Product Delivery

Product Delivery involves the software development practices that take a set of initial requirements and architectural context and result in a working product/service.

In many ways Product Delivery is the “magic box” in which creative science happens that turns requirements into a solution. Using teams with specialist technical skills and a variety of creative problem solving methods products or services are created that create business value. Product Delivery heavily overlaps with the concept of a Project, as both cover the bottom half of the Big Picture of Holistic Software Development (and the H-model) in terms of:

People: notably the Product Customer and de-confliction with the programme space via the Product Forum (or sometimes a Project Manager).

Requirements: from Scoping Diagram downwards to Stories on a Product Backlog and low level plans.

Delivery: in the form of agile/iterative, continuous flow or waterfall teams (see below)

Reporting: in terms of progress metricsvalue stream metrics and Bubble Up escalations.

Operations: in terms of the use of Development EnvironmentsContinuous Integration Environments and Test Environments.

Definitions of Done: from the lowest level of “Developed” to “Product User Acceptance”

Delivery Projects

A Project is a temporary collaborative endeavor undertaken to create a unique product, service or result

(through a series of Releases)

This definition of “Project” is close to the PMBOK standard and points out some key features of a project:

  • It is temporary, once its aim has been met it finishes
  • It is collaborative, it uses people and resources
  • It has a specific goal, normally one primary goal

Strictly by this definition most work to create a product can be considered a “project”. In HSD we often talk about “product development” and “projects” fairly interchangeably because of this. However, the word “project” also invokes ideas around traditional “project management” that can be counter to modern ways of working with embedded bias towards waterfall methods. As a result, we see a lot of focus on “teams”, “cells”, “delivery units” etc. The software industry needs to move past this discomfort. When we use the word “project” in HSD, we mean a temporary collaborate effort to meet a specific goal or create a product through a series of Releases

Project != Project Management

Many organizations stretch the definition of a project to include many different aims, making their projects run for a very long time (sometimes over many years). When organizations do this they change the nature of the “project” into something more similar to a “programme” and yet frequently do not change the practices applied to manage the work. As a result, project management practices are inappropriately applied. If a “project” has many aims and will deliver several products as a large system of systems it is a Programme, not a Project.
If a Project construct is tightly tied to creation of a Product it can be useful, but “projects” and “project management” are not required to deliver a project. Both constructs are used when delivery teams need managing, which is not always the case. Many teams, and many delivery methods are self-managing.
The idea that all work, and all people, need a manager is a myth.

A Project in Holistic Software Development

In Holistic Software Development we consider a software project, whether in explicit form, or an implicit collection of activities and people one of three ways:

1. The Small Picture of HSD

The Small Picture of HSD is essentially a map of a single project.

2. A stand-alone Project

When Projects aren’t part of a programme, they are simply stand-alone projects as part of the Portfolio. This means that their requirements will derive directly from a Business Case (or Portfolio Request) although they won’t need intermediate levels of requirements elaboration or Solution Architecture as the only architectural context is Enterprise Architecture.

The Project boundary is further expanded as a stand-alone project is responsible for raising its product to the highest required level of done and will also normally have product adoption and business change as part of its scope.

3. As part of a Programme

When Projects are part of a Programme they get a lot of context from the programme in the form of requirements (a programme backlog), planning (some form of coordinating roadmap) and architecture (Solution Architecture).

A Programme will normally be responsible for sourcing development and test environments for the Programme as a whole rather than each child project diverging, but sometimes a Project will have to source its own environments if it is unique.

A Project that is part of a Programme will deliver its product to the Programme iteratively and incrementally, if not continuously, for integration with output of other Projects to form a Product Family.

During development we recommend seperation by interface between Project teams, not source sharing dependencies.

The Programme is normally responsible for adoption and business change of the entire solution, delivered incrementally rather than individual Projects.

Due to this structural relationship, Programmes can feel like the customer to Project/Delivery teams. Programmes, may actually be a Business Customer (in that they are coordinating funding) but they are not the Product Customer, which should be a real end-user Customer wherever possible.

If conflict is likely between Programme Business Customers, Product Customers and delivery teams the Product Forum practice is ideally suited to de-conflict the situation.

Projects with Internal Structure

Within a project (in either shape) projects may have internal structure as teams are organized to deliver the primary aim of the project. Teams are often organized into function teams and component teams, delineated by architecture, work streams/packages or other patterns. All have their advantages and disadvantages, the key thing to bear in mind, is that pull is established across each team to the project. Teams must be formed effectively and understand their value proposition to the project and in turn the business. When considering internal project structure be mindful of Conway’s Law.

Critically, the definition of done must be understood between teams without losing focus on the teams’ collective responsibility to deliver the product as a team of teams. More information on cross-team interactions is in the Team-Forming practice.

Projects may encompass a mix of agile/iterative teamscontinuous flow teams and other delivery models as part of Product Delivery.


As mentioned earlier, the “project” construct isn’t necessary for product delivery. Various delivery methods ranging from Incubators, Accelerators, Hackathons, organic cells etc. exist to deliver projects. Sometimes it’s useful to treat all of these things as “projects” as it makes sentences shorter when talking about portfolio management, which is why we often use “project” with a lower case “p” to cover these pieces of work.

The hybrid dynamic model, and HSD in general, embrace multiple methods. We recommend that leaders enable multiple processes to be used in parallel for different types of work. There is little to be gained from standardization of creative knowledge work and a lot to lose.

Project Management

Project/Product Managers act as leaders for teams performing critical communication roles, dealing with stakeholders, coordinating with other teams, mitigating local risks, driving continuous improvement etc. Not all teams need Product/Project Managers as some teams perform these functions as a group.

Delivery in Detail

Delivery involves agile/iterative, continuous flow or waterfall teams turning requirements into working software with intentional system architecture. Regardless of the Team structures used, we strongly recommend that teams are exposed to the full requirements context (including Business Case – Portfolio Requests and Strategic Goal alignment) and architectural context (Solution and Enterprise Architecture) involved in their work.

We’ve seen many dysfunctional projects where the root cause of failure was that teams were not fully informed of strategic goals, requirements and architectural context. This leads to delivery teams working professionally, but in the wrong direction, doing their best but delivering the wrong product demoralizing everyone involved, wasting their valuable resources and losing business opportunities.

To avoid this communicate Product Delivery goals clearly and transparently, engage Product Customers regularly in feedback loops and build both verification and validation into every activity.

Stakeholder management refers to establishing an understanding of stakeholders, relationships, expectations and objectives. Stakeholders are people or organizations who are affected by the outcome of an project, programme or other business activity.

Project Management vs. Product Forum

Holistic Software Development includes two mechanisms for managing Product Delivery: Project Management and the Product Forum.

Project/Product Managers act as leaders for teams performing critical communication roles, dealing with stakeholders, coordinating with other teams, mitigating local risks, driving continuous improvement etc. Not all teams need Product/Project Managers as some teams perform these functions as a group.

The Product Forum is a team-of-teams structure that co-ordinates integration of a Product or Product family.
The Product Forum is a self-organizing, often democratic, group that balances competing voices and concerns, owns high level Requirements and Architecture, runs the high level release stream and performing integration activities for the product.

Rather than impose a hierarchy of decision making from a Programme or Project Manager downwards, the Product Forum is a “middle-out” virtual team in the middle of all stakeholders balancing concerns of Product CustomersBusiness Customers and Business Leadership with Programme and Project Delivery teams. An alternative management structure for cross team working (or managing a large/complex team) the Product Forum can be thought of as an agile alternative to traditional Programme Management.

The choice of model will be based on the culture of the organization, however there is no reason not to mix the models – in fact the Product Forum specifically references Project and Product Managers. Often teams will seek a Project Manager even when they self-organize.

How Delivery Works

As mentioned previously, Holistic Software Development references three types of delivery teams building software, using integration streams to combine their work into a deliverable Release, ensuring the appropriate quality levels and therefore a level of done. All Delivery Teams are encouraged to adopt a Continuous Improvement culture driving organizational Business Change.

Agile/Iterative Teams

Agile/Iterative Teams follow a lightweight, evidence based, adaptive approach to software development. Delivery is frequent, with regular increments adding to an increasingly rich product.

Agile Teams

An agile iterative team will be self-organizing, cross-functional and will deliver regular incremental releases of their product in short iterations or time-boxes (preferred iteration duration measured in weeks). The team will actively engage as a group in detailed planning of their short iterations/sprints and will proactively adapt plans and working practices rather than be directed by management. Self-organization implies the team taking responsibility for their success or failure improving their motivation as they achieve autonomy. A Project Manager may be involved in an agile team to perform leadership, co-ordination and communication activities while the team and Product Customer are responsible for planning.

We recommend Scrum for agile Product Delivery Teams

“Agile” is not just about workflow though, that’s what makes an iterative team. “Agile” is a philosophy, centered in team based social practices where individuals and interactions are valued over processes and tools. Agile teams embrace social interaction, organic networking and a strong focus on working software as the measure of progress. Be wary of derailing agility by focusing on processes (Scrum), measures (velocity) and tools (backlog tools).

Iterative Teams

Iterative teams are very similar to agile teams and will also deliver regular incremental releases of their product in short iterations or time-boxes but are typically controlled by directive management rather than being self-organizing. Planning is often done for the team by a Project Manager who takes on planning responsibilities as well as performing leadership, co-ordination and communication activities.

Agile/Iterative Teams

From a workflow perspective, Agile and Iterative Teams are very similar in nature, both deliver small parts of a system incrementally, batching requirements into timeboxes and both require regular feedback loops. Typical iteration or sprint durations will be 2-4 weeks, represented by a Sprint/Iteration Plan and the order of feature delivery in the increments is determined by balancing customer priorities, technical risk and technical dependencies. If there is conflict between these areas, we recommend de-confliction using the Product Forum practice.

Agile/Iterative teams are intended to be cross-functional, meaning that the team has all of the skills within it to accomplish all that is asked of it. An team therefore requires specialist capability in user experiencerequirementsarchitecture and design, coding, testing and deployment. In practice, within large organizations some specialists will emerge that float between teams, working with them temporarily to advise others for short periods as required, for example to provide expert UX skills. For more see the Team Forming practice.Agile and Iterative teams will practice some form of “Reflect and adapt” or continuous improvement technique at sprint/iteration boundaries. For example, teams using Scrum will schedule and perform a retrospective each and every sprint to identify what can be done better or changed to improve team performance. Iterative teams do the same at Iteration Assessments.

For continuous improvement teams will use some simple performance metrics to assess the amount of work being completed, these metrics can also be extrapolated to predict future milestones based on actual performance.

Continuous Flow Teams

Continuous Flow Teams delivery value one change at a time. Pulling work from a prioritized backlog, typically limiting the amount of work in-progress to smooth flow across delivery activities. Continuous Flow teams work towards a pull from customersreleasing continuously as each change reaches a high “Level of Done“.

Continuous Flow can be thought of as the logical extension of agile/iterative workflow where the length of an iterative timebox is reduced to the length of time taken to completely deliver one backlog item.

Waterfall uses a sequential series of stages to deliver the product in one cycle. Iterative development was introduced to provide shorter feedback loops in the development process and facilitate incremental delivery. Taken to the next stage agile shortened the iterations from months to 2-4 weeks. The next step for many teams is to eliminate the iterations entirely and pull work from their backlog as capacity allows.

Often Continuous Flow teams adopt many Lean and Agile principles and so in practice there are many similarities with agile iterative teams as both are normally cross-functional teams using stories as the primary unit of requirements. Continuous Flow models tend to involve the Product Customer setting the priority of work on the backlog and the team simply processing them in order by taking the next one off the top as work travels through the in-team processes.

Work is pulled through a Continuous Flow process towards delivery. When work is “Done” it leaves a gap in the “In Progress” state which is then filled by the next high priority piece of work. Many teams using a “Kanban board” to visualize their flow will use more fragmented states than our example here but we do recommend keeping the number, and definition, of states simple.

If multiple states are used, then we recommend focusing on definitions of done (e.g. “System Tested”) rather than intermediary process steps (e.g. “Analyzed”).

In many cases, “New”, “In Progress” and “Done” are good enough. We recommend thinking about a final “Value Achieved” state which is based on operational delivery of a “Done” change – the highest possible state of “Done” with the added caveat that positive feedback has been achieved. This extra column helps teams to focus on providing Business Value, establishing pull towards customer needs.

Continuous flow teams strive to attain a smooth flow of work through their pipeline and often use lead and cycle time metrics to improve their performance and throughput of work. A useful aid for understanding the team capacity, backlog, bottlenecks and blockages in the workflow is a kanban style board, used to visualize the team workflow, this should be combined with the implementation of Work in Progress (WIP) limits to control the workflow.

Verification and Validation are built into the completion of every work item meaning that Continuous Flow teams almost always require Continuous Integration practices and often Continuous Deployment practices. Although continuous work can be batched into periodic Releases this tends to lead to driving the workflow back into an agile/iterative pattern losing the benefit of Continuous Flow.

Planning with Continuous Flow

Estimating how long it will take to deliver the backlog can be done by extrapolating based on average throughput of the team. As we mentioned when discussing Estimation in the Planning, Programmes and Projectschapter, such estimation shouldn’t be treated with undue accuracy. Extrapolation and estimation can also be used across multiple releases enabling Release planning. Continuous Delivery provides the best possible evidence and feedback for planning.

Continuous Flow teams often implement a rhythm for regular retrospectives to ensure that they implement feedback loops wider than individual work items, otherwise systemic issues can be missed. When Continuous Flow teams must integrate with other teams they may not be able to get continuous feedback if on-demand integration is out of reach for other teams. In these cases, a continuous team can still deliver continuously but may only get integration feedback based on the Releases cycle of other teams. Collectively applying pressure to shorten release cycles will mitigate quality risks.

Creating a “pull pressure” on integration streams across contributing teams aligned to strategic pull can create pull economics throughout an organization and its value streams leading to efficient workflow behaviors top to bottom.

Continuous Flow teams typically do not need a Project Manager to plan their work but may still require one for communication and leadership functions as with agile/iterative teams.

Waterfall Teams

Waterfall Teams use the waterfall model of development that entails a linear sequential path through requirements definition, analysis, design, development (coding), testing, deployment and maintenance. The waterfall model has been extensively proven* to be badly suited to Software Projects as it is only suitable for trivial, very small time frame, very low risk work with an experienced team where everything is completely predictable.

Often described as the traditional approach to software development, the waterfall approach is characterized by following a set of distinct sequential process stages such as Requirements Definition, Design, Build, Integration, Test, Deployment.

Waterfall’s sequential stages encourage development of intermediate work products to pass information across stage boundaries. Because each stage is done only once it must be fully complete before the next is started. This leads to lengthy up front requirements definition which aims to fully understand system requirements so that they can then be frozen before starting the design stage etc.

This approach leads to the system only being available in one release at the end of the entire lifecycle, often called a “big bang” approach. This means that business value can only be realized at the eventual end of the lifecycle, not in incremental parts, meaning that return on investment is delayed to the end of the project. Critically, the only meaningful point of feedback, when the actual system can be tested and used by customers only happens once, at the very end. Waterfall methods only allow for feedback once, not continuously. Feedback against plans, especially course corrective feedback, simply doesn’t compare to feedback against actual output.

Typically, waterfall approaches lead (by design) to very late integration breakages and bug discovery since testing is only done at the end of the project once coding is complete. In this model, risks are only mitigated at the very end of the lifecycle once testing is complete and behavior is proven.

Waterfall can sometimes feel intuitive as it is simpler to grasp than iterative/agile methods. Waterfall methods seem to make sense for physical construction and sometimes these metaphors are badly used for software development. Waterfall gives a perception of management control since problems aren’t identified until the end of the project. As a result, a project can seem to be executing normally without problems for 90% of its lifecycle as the mess of early tests, bugs and changes is avoided until the end. A common dysfunction in waterfall processes is that as the schedule gets squeezed testing effort is reduced in favor of scope and so quality is diminished.

Is Waterfall ever appropriate?

Waterfall may feel an attractive approach for extremely short, low risk projects, even then a continuous flow model would be preferable as each requirement can be tested (reducing risk) as it’s developed. For larger and/or riskier projects we recommend an iterative approach. For large very low risk projects we recommend splitting the project into parts that can be delivered incrementally or in parallel since there is no reason to assume that low risks never happen, some level of assurance part way through is advantageous.

Splitting a waterfall project into a number of smaller deliveries, with a little up front scoping requirements, architecture and planning is in fact iterative development. Splitting those parts down to the size of the smallest deliverable requirement is a continuous flow model.

We cannot recommend waterfall methods for software development.


Regardless of the team model used we recommend regular team retrospectives to help maintain team communication and cohesiveness.

Retrospectives are periodic team based reviews focusing on what went well and what went wrong so that lessons can be learned and processes improved.