Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Focus Your Retrospective on the Wildly Important

DZone's Guide to

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.

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

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.

Examples

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

Examples

  • 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?

Examples

  • Last PI, our throughput was as below.

    Image title
    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.

Wrap-Up

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.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.

Topics:
agile ,retrospective ,goals ,manager

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}