Making Release Retrospectives Strategic and Effective: Part 5

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. See Part 3 of this blog.
  • Step 3: Use release retrospectives to analyze the strategic metric data, and discuss likely causes for the issues revealed by the metric. See Part 4 of this blog.
  • 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 Steps 4 and 5.

Step 4: Develop appropriate action plan to address the issues identified by strategic metric:  Step 3 brings out the issues identified by the Strategic Metric and their root causes, as exemplified in Table 3 of Part 4.   Senior management should now discuss and develop appropriate action plan to address the issues.  

Table 4 shows examples of possible actions in response to issues revealed by the strategic metric in Step 3 explained above. 

Table 4: Example Action Plan to Address the Issued Revealed by
Strategic Metric of Table 2 of Part 3

Strategic Metric

Action Plan to address the Issues

A. Field data on product feature usage by customers
  • Discontinue rarely used or least used features; and guard against adding similar features in future release cycles
  • Add important missing features or epics in the product backlog
  • Improve, simplify or streamline features that give poor user experience
B. Concept to Customer value realization cycle time
  • Remove identified bottlenecks in the end-to-end process by process reengineering
  • Reduce end-to-end cycle time by simplifying and streamlining the process, and reduce delays and bottlenecks
C. Release cost data in financial terms
  • Reduce development and delivery costs by
    • eliminating rarely used features (see action plan for measure A above)
    • improving release productivity (see action plan for measure D below)
    • increasing automation along the end-to-end value chain
    • using lower-cost external vendors
D. Release Productivity = (Release velocity / Release cost)
  • Improve release velocity by emphasizing better team work, cross-functional team training, automation
  • Reduce release cost (see action plan for measure C above)
E. Number of customer-reported new issues in a given period of time
  • Improve quality with review sessions for feature specification, design, code
  • Offer training and resources for test-driven development, refactoring, test automation, and technical debt reduction
F. Productivity-Quality composite measure = Release Productivity / Number of customer-reported new issues
  • If there is an observed trade-off between Release productivity and Number of customer-reported issues, offer training and consulting help to break the trade-off mindset.  With Quality first, productivity should increase and not go down (don’t fall for a false trade-off trap).

Step 5: Implement the action plan developed in step 4 (see Table 4): Often teams and organizations development wonderful action plans as a result of sprint or release retrospectives, but then fail to implement those actions in the hustle and bustle of the next sprint or release cycle.

The most pragmatic and effective way to implement those well-intentioned actions is to convert them into epics or stories, and schedule them for completion in upcoming release cycle and sprints.  An epic is a large story that cannot be completed in a single sprint; epic action items coming from a release retrospective should be broken down into stories — work units that are small enough to be completed and accepted in a single sprint by an agile team.

Stories of an epic are assigned to multiple sprints of a release cycle.  Each story is then implemented by breaking the story into its tasks, assigning tasks to individual owners that are members of a team, and the owners of the tasks completing them.  Those epics and stories representing action items from release and sprint retrospectives should receive the same treatment and visibility as software development epics and stories.  Retrospective epics and stories should not be relegated to second-class citizenship.  They should be defined, estimated, planned, implemented, tracked, and closed similar to software development epics and stories.  That is a very effective way to ensure that an enterprise and its teams can actually implement retrospective action plans and get the real benefits from retrospectives (inspect, adapt, learn and improve the process); in short, make the retrospectives really effective.

If you are interested in using the Release Retrospective Template for your release retrospectives, please download it here.   This template consolidates in its single worksheet all the examples illustrated in Table 1 through 4 of this multi-part blog series.

Part 1: Overview of Release Retrospective
Part 2: Define strategic objectives and associated strategic metric
Part 3: Conduct periodic measurements to collect data to support the strategic metric
Part 4: Use release retrospectives to analyze the strategic metric data, and discuss likely causes for the issues revealed by the metric

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

One Response to Making Release Retrospectives Strategic and Effective: Part 5

  1. 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>