Concept: My initial posts on AgileES focused on “what” and “why”. That is, I described the concepts behind AgileES and the benefits of using ES on Agile projects. The focus then shifted to “how to": Seven steps detailed how to apply ES to Agile projects. Closing off the "how-to" steps is a final one that references several of the previous steps in a repeating cycle. Although not called out in the step name, the final step also includes status reporting. Again, I start off by acknowledging and addressing canonical Agile objections before detailing the practice.
Practice: Once performance is assessed and the next Sprint is planned, the project is in an excellent position to update Stakeholders outside the team. Status reporting at this point seems to be a natural next step, but there’s a problem.
Many Agile proponents harbor a deep-seated animus toward status reporting. The blogosphere is rife with sentiments such as this: “the idea of a ‘project status’ is utter nonsense in a Scrum or Open Agile setting “. [1] Although its intention is humor, the Dilbert comic captures a scenario that many Agile proponents regard as commonplace fact:
In this view, status reports are imposed by management in lieu of constructive action. The reports are worse than useless because producing them takes time that would otherwise be spent producing deliverables.
In a variation on the complaint, advocates of self-managed Agile teams believe that participation in the project is the only way to understand its status. Again, in words from the blogosphere: "Someone who cannot be bothered to participate in any of these events [i.e., Sprint planning or Daily Scrums] is generally someone not worth involving in the project”. [2]
And, once again, a Dilbert cartoon captures the attitude:
Behind the animus lurks the myth of the Pointy-Haired Boss. The idea is that managers are value-free politicians who waste the team’s time with useless demands—of which status reporting is the chief culprit.
Granted, “pointy-haired” managers à la Dilbert exist, but many more managers take seriously the fiduciary responsibility of their position. They have a duty to understand how their (or, more often, their shareholders’) money is being spent. That means they need to understand how things are going on the projects in their portfolio—and, not just on major releases but on each Sprint.
At the same time, managers often have a wide span of authority, especially given the down-sized organizations that are the rule today. The size of project portfolios makes it practically impossible for managers to participate as a team member on all projects. It is, therefore, up to project teams to provide managers and related Stakeholders with the information they need to perform their duties.
AgileES gives project teams a way to meet Stakeholder needs for status information and to do so with little or no incremental impact on the team’s time. Steps 3-7 produce data for Sprint planning. The data can easily be re-purposed to provide Stakeholders with the information they need.
So, at the end of a Sprint, Steps 3-7 should be repeated, and a status report should be produced.
8. Repeat Steps 3-7. (And, Produce status report.)
To see how this works, let’s return to the example cited in previous posts.
Recall that, in the example, results from the first three Sprints necessitated a new baseline and along with it, new estimates, risk analysis, Contingency and Reserve allowances, and start/finish dates.
Now, consider what happens at the end of Sprint 7. Figure 1 is a snapshot taken at that point. [3]
Figure 1
The ES Burndown line (blue circles) hovers at or slightly above the Baseline ES Burndown line (brown squares), giving the impression that the project is on or slightly behind schedule. [4] The impression is not sufficient for Sprint planning. It does not clearly indicate whether the performance shortfall is serious enough to delay the project. If the project is delayed, by how much will it be delayed? The gap looks small, but is it reasonable to continue with the baseline, or should the re-baselining process be started? The answer is in the detailed metrics.
Here is the “chicklet” table for the key measures.
Figure 2
After the first Sprint of the new baseline, the Schedule Performance Index for time (SPIt) was consistently above .95. Unlike the old baseline (Sprints 1-3), the Rate of Discovery (RoD) did not show a series of large jumps—it was steadily within Contingency. Both metrics were re-assuring signs, as evidenced by the Green status indicators. [5]
By contrast, the Estimate at Completion for time (EACt) signaled caution. The estimated finish date was always beyond Contingency. That meant the Baseline Finish Date was in doubt. On the other hand, the amount of overrun stayed within Reserve during Sprints 5-9. That meant the Committed Finish Date was intact, but Reserve would be required.
Releasing Reserve is a non-trivial event. If Reserve is released early in a project, the current commitment is at great risk, as a re-baseline is often required. If Reserve is released late in the project, the existing baseline persists, as long as the Committed Finish Date remains intact.
If Reserve is released and the baseline kept the same, the estimated velocity does not change. The Baseline Duration remains the same, and the Baseline Budget at Completion (BAC) is unaffected.
Yet, performance on Reserve must be tracked along with the baseline. New Planned Release Points (PRP) associated with the Reserve are included in the PRP count for calculations of Actual Percent Complete (APC), Planned Value (PV), and Earned Value (EV). Although it is sometimes overlooked, release of Reserve is also reflected in the project timeline through the addition of one or more sprints.
In the example, the project team was confident that the Committed Finish Date would be met and retained the baseline. [6] At the same time, the team recognized that Reserve would be required and prepared management for making a decision on its release.
The status report at that time included the ES Burndown Chart, a description of the issue that affected the finish date, and a warning that Reserve needed to be released. A snapshot of the report is included below. (Click on the image for links to full-sized views of the report.)
Figure 3
In the end, Reserve was released but late in the project (Sprint 11). New PRPs associated with Reserve were included in calculations of APC and PV as soon as Reserve was released and in EV once the RPs were done.
Figure 4 is the final chart from the project. For completeness, the final “chicklet” table is shown in Figure 5. As estimated, the project finished beyond Contingency but within Reserve.
Figure 4
Figure 5
Notes
[1] Aaronaught (2013a).
[3] In the old baseline, this would have been the end of Sprint 10. Also, note that the example is based on a single rate for all Release Points, rather than a variable rate.
[4] The assumption here is that a single, blended rate applies to each and every Release Point.
[5] It should be noted that the RoD was at the maximum allowance including both Contingency and Reserve. So, although it was by definition still “Green” it was on the borderline with “Yellow”.
|
