Making Release Retrospectives Strategic and Effective: Part 3

In Part 1 of this multi-part blog series, I presented the case for tying release retrospectives with strategic objectives and strategic metric, and outlined a 5-step process for defining strategic objectives to drive agile transition in an enterprise:

  • Step 1: Define strategic objectives and associated strategic metric. See Part 2 of this blog.
  • Step 2: Conduct periodic measurements to collect data to support the strategic metric
  • Step 3: Use release retrospectives to analyze the strategic metric data, and discuss likely causes for the issues revealed by the metric
  • Step 4: Develop appropriate action plan to address the issues revealed by the strategic metric
  • Step 5: Implement the action plan developed in step 4.

In this part, I will elaborate on Step 2.

Step 2: Conduct periodic measurements to gather data and measure strategic metric: Once the strategic objectives and corresponding strategic metric are defined in Step 1, ScrumMasters, Project and Program managers need to decide how to collect the data to support the metric.  This is a serious and often a sizable effort.  It requires expertise, commitment, allocated time, resources and budget.  However, collecting data for the metric should not be a goal in itself, it is only a means for the management to evaluate where the enterprise stands in its agile transition at present, and to make mid-course corrections to help the enterprise reach its strategic objectives.

Table 2 includes the strategic metric presented in Table 1 of Part 1 of this blog series, and shows corresponding measurement approach for each metric.

Table 2: Examples of Strategic Metric and its Measurement Approaches

Strategic Metric

Measurement Approaches

A. Field data on product feature usage by customers   Customer surveys to understand which features of a product are being used and how frequently; and which features may be missing or are difficult to use and need to be improved.

  • Feature usage distribution and frequency: always used, often used, sometime used, rarely used, never used
  • Features that are missing
  • Features that need to be improved
  • Features that need to be simplified or streamlined
B. Concept to Customer value realization cycle time   Measure the cycle time from the concept creation until a feature(s) realizing that concept produces business value for the customer.  Various elements of this value chain are broken down as a sequence or a network of steps, and each step is measured in terms of elapsed time.

  • End-to-end cycle time
  • End-to-end process bottlenecks
  • (Value producing time / Total cycle time) ratio for the value chain
C. Release cost data in financial terms  Measure fully loaded development and delivery cost: people, material, equipment, licenses, shared IT service charges, etc.
D. Release productivity = (Release velocity / Release cost)  As a release consists of a sequence of sprints and multiple teams may be involved, it is important to normalize the velocity numbers across sprints and teams to account for the fact that story points across sprints and across teams may represent different amount of work.  Without story point normalization, story point math will not make sense.   Story point normalization is a complex topic and is outside the scope of this blog series.
E. Number of customer-reported new issues in a given period of time  This metric and its measurement are self-explanatory.  Typically this number can be reported on a quarterly basis, or for the entire release cycle.
F. Productivity-Quality composite measure = Release Productivity / Number of customer-reported new issues  This measure combines the data from measures D and E.

 

As the strategic metric data are periodically collected (typically on a quarterly basis or after each release cycle), senior management team should set measurable target goals for the next one to four quarters or release cycles.   These goals should provide concrete guidance to agile teams in their release retrospectives and developing action plan based on those retrospectives.

When an enterprise is just starting out on its agile transition, it may not be possible to set target goals for the strategic metric due to lack of historical data.  But after a couple of release cycles, there should be adequate historical metric data available to set up the target goals for future release cycles.  If an enterprise completes all the effort outlined in Part 1 and 2 of this blog in the first few months after the agile transition has started, the enterprise can take satisfaction in having made good progress.

In Part 4 of this multi-part blog series, I will present the details of Step 3: Use release retrospectives to analyze the strategic metric and likely causes for the issues revealed by the metric: 

Part 1: Overview of Release Retrospective
Part 2: Define strategic objectives and associated strategic metric
Part 4: Use release retrospectives to analyze the strategic metric data, and discuss likely causes for the issues revealed by the metric
Part 5: Developing and Implementing the Action Plan

This entry was posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Metrics. Bookmark the permalink.

2 Responses to Making Release Retrospectives Strategic and Effective: Part 3

  1. Pingback: Making Release Retrospectives Strategic and Effective: Part 2 | The Agile Management Blog

  2. Pingback: Making Release Retrospectives Strategic and Eff...

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>