Making Release Retrospectives Strategic and Effective: Part 4
Last Updated Jul 15, 2013 — Enterprise Agile Planning expert
Enterprise Agile Planning
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
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 3.
Step 3: Use release retrospectives to analyze the strategic metric and likely causes for the issues revealed by the metric: A release retrospective should be held at the end of a release cycle to review and analyze the strategic metric measurements, and likely causes for the issues revealed by the metric. This is how you tie release retrospectives with strategic objectives and metric, and make release retrospective of strategic importance. The release retrospective meeting or session is attended by all team members, ScrumMasters and Product Owners for the release cycle, and appropriate managers. It is important that the strategic metric data are collected (as explained in Step 2 above – see Part 3 of this blog series) ahead of a release retrospective. The data are reviewed and analyzed at the Release Retrospective meeting.
Table 3 shows examples of issues revealed by the strategic metric. In a release retrospective, the participants should identify the issues revealed by the strategic metric, and start discussing the root causes that may be responsible for them. This analysis of root causes may continue even after the release retrospective is over, as it may require more in-depth analysis. If the root cause is not identified, at best only symptoms may be treated, and the issues will continue to recur.
Table 3: Analysis of the strategic metric and likely causes for the issues identified with the metric
Identify Issues and perform root cause analysis
A. Field data on product feature usage by customers
Identify rarely used or least used features
Identify important missing features
Identify features that give poor user experience or are difficult to use
B. Concept to Customer value realization cycle time
Identify bottlenecks and causes of delays, and waiting periods and buffers in the existing end-to-end process from concept to customer value realization
C. Release cost data in financial terms
Break down the release cost for development and delivery into its component to identify the contribution of different cost components
Cost and opportunity cost represented by rarely used features
Cost represented by poor release productivity
Cost represented by poor level of automation along the end-to-end value chain (automated unit tests, automated QA tests, automated regression test, automated acceptance test, automated build process, lack of continuous integration, etc.)
Cost represented by personnel
Cost represented by equipment (Dev and QA environment, build machines
Cost represented by software licenses: Development tools, QA tools
D. Release Productivity = (Release velocity / Release cost)
Example factors that may have reduced release productivity:
Poor performance of cross-functional teams
Low degree of automation
Lack of skills and training issues
Multiplexing and multitasking
E. Number of customer-reported new issues in a given period of time
Identify issues that could have been prevented with rigorous design review
Identify issues that could have been prevented with rigorous code review
Identify issues that could have been prevented with rigorous unit testing by developers
Identify issues that could have been prevented with rigorous QA testing by QA testers
Identify issues that could have been prevented from more effective customer training and support
F. Productivity-Quality composite measure = Release Productivity / Number of customer-reported new issues
Does the metric suggest that the team is treating productivity and quality as two competing factors that must be traded off; therefore, any attempt to increase productivity invariably reduces quality, and vice versa?
Identify lack of any skills or training issues
For all issues identified and their root causes analyzed (as exemplified in Table 3), senior management should ask these questions for each strategic objective and the associated target goal:
Did we meet our target goal or did we fall short of it?
If we fall short on a target goal, by what amount?
If we fall short, what might be the root cause?
What trend are we seeing? Is the trend improving in the right direction or going in a wrong direction, i.e., deteriorating? What might be the root cause for the deterioration?
In Part 5 of this multi-part blog series, I will present the details of Step 4: Develop appropriate action plan to address the issues identified by the strategic metric, and Step 5: Implement the action plan developed in step 4.
PI Planning aims to bring together all the people doing the work and empower them to plan, estimate, innovate, and commit to work that aligns with the business’s high-level goals, vision, and strategy.
Silvia Davis, Sr. Product Marketing Manager at Digital.ai, tells her story of how a positive app experience led to the realization that proper data integration is essential to the entire application lifecycle.
Regardless of where you are on your digital transformation journey, we can help you achieve your strategic outcomes and accelerate value delivery with the right combination of technology, services, and training.