CHAPTER 16

Agile Product Delivery

Agile product delivery is the interplay between monitoring and control and at the project level, monitoring and control at the product delivery level, and system engineering (characterizing the specialist domain) (see Figure 16.1). Monitoring and control at the project level follows the stage-gate paradigm of HybridP3M and is a project management layer. Monitoring and control at the product delivery level deals with work packages and is a team management layer below the project management layer. These two processes are inspired by both PRINCE2 (i.e., controlling a stage and managing product delivery) and the Praxis framework (i.e., delivery process and development process), which have a similar approach to the management of work packages. Combined, the two monitoring and control processes capture a simple loop representing the flow of work packages. This loop can be repeated by new work triggers calling for additional work packages. System engineering includes specialist development work and other activities that contribute to the integrity of the end product. It is extreme, excluding any kind of unnecessary overhead, and inspired by Extreme Programming. So Agile product delivery is contextual and situated, not a superficial or simple Agile approach. The added value of monitoring and control at the project level is management control. The added value of monitoring and control at the product delivery level is controlled work execution. And the extreme approach to system engineering adds to agility. In this chapter, all three core process groups are elaborated without going into too much detail of every activity. The actual workflow can be derived from Figure 16.1.

Monitoring and Controland at the Project Level

Monitoring and control at the project level starts when the project manager authorizes a work package (triggering “authorize work” adopted from Praxis framework). The follow-up activity is “coordinate and monitor progress,” also adopted from Praxis, a more comprehensive counterpart of “review work package status” in PRINCE2. That is to say, “coordinate and monitor progress” follows work package execution or is triggered when completed work packages are received by the project manager. The next activity depends on the type of product delivery (delivery mode): predictive or Agile. This split is represented by a decision in the flow of activity as can be noted in Figure 16.1 (see the “decision diamond” that follows “co-ordinate and monitor progress”). In case of predictive delivery, the next activity is “compare stage status against baselines plans” (the PRINCE2 equivalent is “review the stage status”). Here the project manager (or controller) is dealing with management-by-exception. In case of Agile delivery, on the other hand, another decision follows. There are three decision outcomes here: (1) the stage or project ends (by whatever reason), (2) project-level changes apply, or (3) anything else. Note that “decision diamonds” not necessarily represent decision moments; more important are the unique conditions that lay out a path in terms of workflow. The first option leads to a boundaries process, for example, the PRINCE2 process of managing stage boundaries or, alternatively, closing a project. The second option plays an essential role in Agile project management as the project management team needs to anticipate change (a case for Agile project management). If project-level changes apply, the next activity is to take corrective action. Following corrective action, a work trigger may follow reinitiating the authorization of work, the beginning of a new loop. The third option, anything else, merges with another distinct decision diamond (see Figure 16.1). Back to predictive delivery, what follows “compare stage status against baseline plans” is a similar decision diamond with three options: (1) the stage or project ends, (2) stage or project is within tolerance, or (3) corrective actions are needed. The first option, just like in Agile delivery, leads to a boundaries process. The second option leads to a new decision diamond, either a new work trigger or the activity of “report highlights” based on communication needs. And the third option leads to “take corrective action,” relevant in both scenarios (predictive and Agile) but based on different needs (predictive capability versus agility). Finally, there are two more independent activities in monitoring and control at the project level, namely “capture and examine issues and risks,” adopted from PRINCE2, and “take measures,” triggered by the former. These two activities are more continuous in nature. Note that “capture and examine issues and risks” may result in a work trigger. Taking measures may imply taking corrective action or result in escalation. In case of escalation, there is an interface with directing a project, calling for “give ad-hoc direction” (by the project board), a PRINCE2 activity. In conclusion, monitoring and control at the project level is partly a flexible process that can be adjusted according to a predictive or Agile delivery mode.

Figure 16.1 Agile product delivery PDD

Monitoring and Control at the Product Delivery Level

The process of monitoring and control at the product delivery level starts with accepting a work package, which is triggered by the project manager who authorizes new work packages to the team manager. Following this, the work package is executed. After completion, the work package is delivered to the project manager, who is the receiver of the completed work package. Compared to PRINCE2 and Praxis framework equivalent, HybridP3M’s monitoring and control process includes two additional activities. The first one is to redefine a work package. This activity interfaces with system engineering. When technical specialists perform specialist work, they end up with evaluating the assigned work package. Based on actual development work, as work execution unfolds, they may conclude that the currently defined work package does not correspond well to actual delivery. For example, implemented features and lower-level requirements may differ from planned features or requirements. In that case they provide feedback to the team manager, who may redefine the work package based on this new input. The second activity that follows is to update the requirements based on changes. These two new activities make work packages, and thus the management of product delivery, more agile. Monitoring and control at the product delivery level, combined with extreme system engineering discussed next, is both incremental and iterative, another Agile characteristic.

System Engineering

In today’s business, system engineering is one of the most common project and program types. Therefore, this domain is used as the starting point for Agile product delivery. For other types of projects and programs, more focused on intangible project outcomes like change or capability development, this system engineering approach has limited use, but nonetheless may provide inspiration. Also civil engineering projects may greatly benefit from a system engineering approach, having similar technical phases (like gathering of requirements, design, construction, etc.). Technical work is triggered by the activity of performing work (adopted from Praxis framework), controlled by the team manager. Technical work consists mainly of domain-specific specialist work (like designing, programming, etc.). In addition, technical work implies evaluation of the work package issued by the team manager. The latter activity provides an interface to monitoring and control at the product delivery level, namely redefining a work package. This interface supports multiple (agile) iterations in the context of one work package, with redefinitions. If there are no more iterations, what follows is continuous integration. Continuous integration ensures that the technical work related to the current work package is integrated with the rest of the system, possibly the end product. This may require some form of configuration management like version control, as popularized by PRINCE2. After continuous integration follows testing. In an Agile setting, testing is a rather continuous process, not a separate technical phase later in the development cycle. Testing may trigger another iteration to perform specialist work again. This could be caused by the need to make improvements or rework. If testing does not trigger new iterations, especially when the new functionality has gained user acceptance (in a demo environment), it is safe to trigger the delivery of the work package, ending the cycle. User involvement is not always the case, however, at this stage as testing is usually performed by specialists. After the delivery of products, there might be a need for deployment. If that is the case, the next activity is to provide a small release (of the system or component). Following this, the customer is expected to provide feedback, which is collected in an issue log. Based on this information, requirements management is triggered based on new customer wishes. Requirements management, in turn, may trigger the definition of new work packages or modification of existing ones. Hence, another iteration may follow beginning with the activity to authorize a new work package by the project manager. Finally, when there are no more iterations left in the context of stages and the project as a whole, the project life cycle ends and marks the transition to the maintenance phase as part of a product life cycle. Note that with the advent of DevOps, the ending of the project life cycle might be blurred. The first activity in the context of the maintenance phase is to appoint a maintenance team to continue work on the product and its features. Following it are new iterations, again starting with the activity to authorize work packages, repeating the management and development cycle. So even after project completion, the principle of management by stages holds. If there are no more iterations left over a certain time span, the final activity is to provide an updated release. Based on this description and as you can read from the diagram, Agile product delivery is highly iterative and thus agile, yet a controlled process.

Process Aspects

Figure 16.2 captures the knowledge nature of Agile product delivery.

Figure 16.2 Tacit–explicit continuum of Agile product delivery

From a process perspective, delivery depends on explicit process knowledge. The specialist activities as part of delivery also involve a great deal of tacit knowledge.

Figure 16.3 captures the manageability of Agile product delivery.

Figure 16.3 Step-by-step process versus skilled activity continuum of Agile product delivery

Although HybridP3M’s delivery process is complex, the related work-flow can be managed and standardized.

Figure 16.4 captures the specialization level of Agile product delivery.

Figure 16.4 Management–specialist continuum of Agile product delivery

Delivery management, disregarding specialist work, is rather a team effort performed by the project manager and team manager(s). The team management aspect of delivery is arguably a specialization. In practice, however, the team manager role can be combined with the project manager role.

Figure 16.5 captures IT support in relation to Agile product delivery.

Figure 16.5 Available IT support for Agile product delivery

Delivery can be supported by task management software or workflow management solutions. While beneficial in some cases, software is not essential.

Figure 16.6 captures the complexity of Agile product delivery.

Figure 16.6 Task complexity scale of Agile product delivery

Given the combination of monitoring and control at the project and delivery levels, and all specialist activities, delivery is a very complex process. It is even more complex given the incremental and iterative nature of system development.

MAIDEO Requirements

Table 16.1 presents MAIDEO requirements related to “Agile product delivery.”

Table 16.1 MAIDEO requirements related to Agile product delivery