Concept: My posts on AgileES have thus far focused on “what” and “why”. That is, I’ve described the concepts behind AgileES and the benefits of using ES on Agile projects. It’s now time to shift the focus to “how to”. The next posts describe how to apply ES to Agile projects. There are several steps. Some of the steps, especially the initial ones, are controversial. In explaining each step, I will identify and address the issues and then describe the actions to be taken.
Practice: “New Baseline, New Project”: that’s how Walt Lipke summed up the impact of re-baselining. [1] Why think that a new baseline constitutes a new project? Because the structural and political impacts of a re-baseline ripple from one end of the project to the other.
Impacts on Project Structure
When a project fits the criteria for re-baselining, it’s judged to no longer be capable of meeting its commitments, specifically the baseline and committed finish dates. [2] Revised estimates are required.
The first step is to groom the Product Backlog. The grooming identifies Backlog Items that are incomplete, new, or unnecessary. The Release Point count is adjusted to reflect the amended Backlog and associated estimates.
The risk analysis must then be updated and, with it, allowances for Contingency and Reserve. As the Contingency allowance is tied to specific deliverables, further changes in the Release Point total are required.
A new Release Point total generally leads to changes in finish dates. In turn, new dates prompt the review of and updates to staffing. Once the staffing is settled, the expected velocity is re-set. A new start, finish, and baseline burndown follow. [3]
Note that metrics from completed Sprints can be retained for historical purposes—overall project accounting usually demands it. Performance on the re-started project, however, is measured solely against the new baseline.
The structural impacts are significant, but the political ones are even more dramatic.
Political Impacts
Setting a new baseline demands a round of communication, negotiation, and approval, as the old commitments cannot be met. In most companies, there are penalties for not meeting commitments. So, teams hesitate to re-baseline even though they know that’s the right thing to do. Instead, they look for ways to fly below the radar.
What’s required is a culture that supports re-baselining. Insofar as Agile highly values change, it promotes a culture open to re-baselining. Unfortunately, Agile does not highly value following a plan, and that undermines its support for re-baselining.
A better approach is needed. How do you create a “re-baseline friendly” culture? Although culture changes are notoriously difficult to achieve, here are some steps toward that goal. [4]
- Draft predetermined, simple, transparent criteria for when to re-baseline. The
decision to re-baseline is fraught with emotion for both the team and stakeholders. Defuse the emotion by introducing the criteria at the start of the project, rather than in the heat of battle. Make sure that the criteria are easy for everyone to understand. It also helps to ensure that data for the assessment can be assembled without undue effort. Finally, it’s vital that the criteria be transparent. That means the criteria are the same for all projects, assessment data are readily verifiable, and the assessment process and results are public.
- Expand the company’s definition of project success to include re-baselines. Awards for on-time, on-budget projects are common, but unheard-of for re-baselines. Yet, because the price of innovation is risk, the projects most likely to need re-baselines are the innovative ones. Even so, it’s better to encourage well-thought-out innovative projects and risk re-baselines. The alternative is to retreat into projects which are safe but unprofitable. In the end, it’s best to treat re-baselines as another type of successful project.
- Communicate re-baselines as positively and widely as project close-outs. Celebrate not only project close-outs but also reincarnations. Ensure that the organization is apprised formally and positively when a project is re-baselined. The publicity will encourage teams to risk innovative projects and to objectively assess whether a re-baseline is necessary.
There are a couple caveats to these steps.
Immature Baselines: Don’t mistake an immature baseline for a re-baseline. Early in Agile projects, it’s common for baselines to fluctuate. It often takes several iterations before the baseline stabilizes. If each of the iterations is declared as a re-baseline, the designation becomes meaningless. Wait until a pattern emerges. Then, use the criteria to assess if a genuine re-baseline is required.
Zombie Projects: A zombie project is one that “keep[s] shuffling along, sucking up resources without any real hope of having a meaningful impact on the company’s strategy or revenue prospects”. [5] How do you recognize a zombie project? Watch for multiple, frequent re-baselines. We use the following rule-of-thumb: if three or more re-baselines occur in a period covering half (or less) of the planned timeline, the project is a zombie. It’s better off dead.
Notes and References:
[1] Lipke, W. Earned Schedule, Raleigh, NC: Lulu Publishing 2009, p 69..
[3] The new baseline almost always entails changes in cost. As the focus here is on schedule, the impacts on budget are not addressed.
|
