- A Paradigm Shift
- Contrasting Paradigms
- Attention to Flow
- One Work Item Database
- Fit the Process to the Project
- Summary
Contrasting Paradigms
The inherent uncertainty in software projects makes it difficult to estimate tasks correctly, which creates a high variance in the accuracy of the estimates. A common misconception is that the variance is acceptable because the positive and negative variations average out. However, because software projects are long chains of dependent events, the variation itself accumulates in the form of downstream delays.7
Unfortunately, most accepted project management wisdom comes from the world of roads and bridges. In that world, design risks are low, design cost is small relative to build cost, and the opportunity to deliver incremental value is rare. (You can’t drive across a half-finished bridge!) With this style of project management, you determine an engineering design early, carefully decompose the design into implementation tasks, schedule and resource the tasks according to their dependencies and resource availability, and monitor the project by checking off tasks as completed (or tracking percentages completed). For simplicity, I’ll call this style of project management the work-down approach because it is easily envisioned as burning down a list of tasks.
The work-down approach succeeds for engineering projects with low risk, low variance, and well-understood design. Many IT projects, for example, are customizations of commercial-off-the-shelf software (COTS), such as enterprise resource planning systems. Often, the development is a small part of the project relative to the business analysis, project management, and testing. Typically, these projects have lower variability than new development projects, so the wisdom of roads and bridges works better for them than for new development.
Since 1992,8 there has been a growing challenge to the work-down wisdom about software process. No single term has captured the emerging paradigm, but for simplicity, I’ll call this the value-up approach. And as happens with new paradigms, the value-up view has appeared in fits and starts (see Figure 1.2).
Figure 1.2 The attitudinal difference between work-down and value-up is in the primary measurement. Work-down treats the project as a fixed stock of tasks at some cost that need completion and measures the expenditure against those tasks. Value-up measures value delivered at each point in time and treats the inputs as variable flows rather than a fixed stock.
An example of the value-up school is the agile project management manifesto Declaration of Interdependence.9 It states six principles that characterize value-up:
We increase return on investment by making continuous flow of value our focus.
We deliver reliable results by engaging customers in frequent interactions and shared ownership.
We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
We boost performance through group accountability for results and shared responsibility for team effectiveness.
We improve effectiveness and reliability through situationally specific strategies, processes, and practices.
Behind these principles is a significantly different point of view about practices between the work-down and value-up mindsets. Table 1.1 below summarizes the differences.
Table 1.1 Attitudinal Differences Between Work-Down and Value-Up Paradigms
Core Assumption |
Work-Down Attitude |
Value-Up Attitude |
Planning and change process |
Planning and design are the most important activities to get right. You need to do these initially, establish accountability to plan, monitor against the plan, and carefully prevent change from creeping in. |
Change happens; embrace it. Planning and design will continue through the project. Therefore, you should invest in just enough planning and design to understand risk and to manage the next small increment. |
Primary measurement |
Task completion. Because we know the steps to achieve the end goal, we can measure every intermediate deliverable and compute earned value running as the percentage of hours planned to be spent by now versus the hours planned to be spent to completion. |
Only deliverables that the customer values (working software, completed documentation, etc.) count. You need to measure the flow of the work streams by managing queues that deliver customer value and treat all interim measures skeptically. |
Definition of quality |
Conformance to specification. That’s why you need to get the specs right at the beginning. |
Value to the customer. This perception can (and probably will) change. The customer might not be able to articulate how to deliver the value until working software is initially delivered. Therefore, keep options open, optimize for continual delivery, and don’t specify too much too soon. |
Acceptance of variance |
Tasks can be identified and estimated in a deterministic way. You don’t need to pay attention to variance. |
Variance is part of all process flows, natural and man-made. To achieve predictability, you need to understand and reduce the variance. |
Intermediate work products |
Documents, models, and other intermediate artifacts are necessary to decompose the design and plan tasks, and they provide the necessary way to measure intermediate progress. |
Intermediate documentation should minimize the uncer tainty and variation in order to improve flow. Beyond that, they are unnecessary. |
Troubleshooting approach |
The constraints of time, resource, functionality, and quality determine what you can achieve. If you adjust one, you need to adjust the others. Control change carefully to make sure that there are no unmanaged changes to the plan. |
The constraints may or may not be related to time, resource, functionality, or quality. Instead, identify the primary bottleneck in the flow of value, work it until it is no longer the primary one, and then attack the next one. Keep reducing variance to ensure smoother flow. |
Approach to trust |
People need to be monitored and compared to standards. Management should use incentives to reward individuals for their performance relative to the plan. |
Pride of workmanship and teamwork are more effective motivators than individual incentives. Trustworthy transparency, where all team members can see the overall team’s performance data, works better than management directives. |