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

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