Focus Your Retrospective on the Wildly Important
Focus Your Retrospective on the Wildly Important
Follow these steps to select a wildly important goal, incorporate it into your retrospectives, and follow through with achieving it.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Probably the defining element in Modern Business Management is frequently pausing to reflect on events, and using insights gained to set the next direction. Whether it’s inside focused on organisational effectiveness, or outside focused on customer needs and experience, the art of the retrospective gives the essential reality check needed to inform an organisation’s next step.
However, left uncultivated, the retrospective quickly turns into a very shallow discussion of recent irritations and small successes, leading to what Dr. W. Edwards Deming called ‘tampering’ – short term action on a relatively stable system. Because this leads to little fundamental improvement, participants and stakeholders alike lose interest and the practice falls into disrepair and disuse.
Good facilitation can help with this, as can a strong structure that grounds the reflection in the full experience, not just what’s top of mind.
However, the thing that will truly make an impact is focusing on one wildly important goal, and working out what we can change to achieve it.
First: Pick a Wildly Important Outcome Goal
This will be something that makes a significant impact on your organisation’s success. It might be ‘reduce idea->value lead time from 50 weeks to 2 weeks’ or ‘zero defects in production’ or ‘become Number 1 in our market for Customer Satisfaction.’ Or it could be clearly articulated in a financial business case, such as ‘increase revenue by 300%.’ This will be a true result of improvement, and can be aspirational enough to be a never-reached North Star.
Whatever you pick will be a lagging metric; something that is very hard to attack directly, and even harder to attribute to any single improvement, not least because there is delay between actions and movements in the outcome.
Second: Form a Hypothesis
While you cannot easily attack an Outcome directly, you should be able to form a hypothesis about what you can change that will influence the Outcome towards your goal.
If we increase our automated test coverage, so that we have an extensive suite that runs at every check-in, we will reduce the probability of regression defects, thus eliminating one class of defects that escape into production.
If we constrain our Work in Progress, by Little’s Law (and other factors), we will reduce the amount of time work waits in our end to end system.
Third: Pick a Wildly Important, Controllable, Leading Metric
As the examples above show, you can usually link a faster moving metric that is within your scope of control, movement in which will provide an advance indicator that your Outcome will move. Or at least, that’s what your hypothesis claims.
Now you have an intermediate goal – a challenge that can be worked on for 3-12 months in the expectation that achieving it will move the Outcome towards the Wildly Important Goal, and progress seen over a matter of weeks rather than years.
Over this year, we will work to reduce the number of initiatives in our system
In the next 90 days, we will increase the percentage of our codebase’s scenarios that have automated acceptance and unit tests
Fourth: Make Diagnosis and Improvement of the Wildly Important Metric a Central Element of Every Retrospective
While retrospectives should still contain an open questioning of what’s working well (so that we can amplify it) and what’s not (so we can damp or fix it), every retrospective at every level should focus on moving the Wildly Important Metric, while not breaking anything important in its pursuit.
Every retrospective, and every planning session should have as one of its main themes: What’s the progress on our WIM? and What elements of it can we impact next time?
Last PI, our throughput was as below.
In the next PI, we will focus on reducing the number of initiatives we start, aiming to reduce it below the number we finished in the same timeframe. This will initially prevent the WiP problem from getting any worse, and as it reduces below the completion rate, provide an easy mechanism to reduce the total amount”
Last Iteration, we moved to ensuring that all new stories have automated Unit and Acceptance Tests. We will continue with this, while adding Tests to existing functionality in all codebase areas we touch in the next Iteration, cleaning up as we go.
Improvement after improvement, your focus will move the Leading Metric, and if your hypothesis is correct, over time, you will achieve your Wildly Important Goal.
Leader Takeaway: pick a single leading metric linked to a key medium term outcome and use retrospectives to align your team and prompt their intent to autonomous improvement activities towards the outcome.
Published at DZone with permission of Martin Burns , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.