Long term average pace > short term pace
One of the most common challenges I have coached teams on is how to think about their continuous improvement efforts. How we think about pace over the short and long term is a key factor in success.
One of the most common challenges I have coached teams on is how to think about their continuous improvement efforts. This can be particularly acute if they are coming from an environment that was previously a feature factory. A team can be iterating and conducting regular reviews but not seeing the improvement trajectory that would take them to their aspired level of quality and productivity. Over an extended period that can be demoralising and the expected level of customer experience is never met.
A common misconception I see many teams have is that iterative development is for them literally a sprint to get as many tasks done in a short window. Possibly this is a side-effect of us using words like āSprintsā in connection with iterations but I think more likely this is actually the result of a very human trait to opt for things that are more certain to be completed in the time window.
The more serious issue with this is that this pattern gets repeated in successive iterations and the bias to opt for more certain options other than those that are less certain, compounds over time. This in effect places a ceiling in terms of the progress that can be made even when ācontinuously improvingāĀ becauseĀ theyĀ areĀ excludingĀ choicesĀ whichĀ mayĀ payĀ offĀ overĀ aĀ longerĀ period.
An approach to achieving a better balance which can work against our natural bias to seek certainty is to get very explicit about what significant improvement good bring us. I find a number of practices in concert together can help teams to see what may not be obvious when they are at the coal-face.
Two steps I take which I have found to help teams in this situation:
Can the team recognise the pattern they are in? I will review the above diagram above with the teamāāāto behave differently we must recognise the failure pattern. I often draw it on a whiteboard whilst talking through it. I also feature it in regular presentations about delivery and focusing on outcomesĀ forĀ reinforcement.
Can the team picture and align on an ideal futureĀ toĀ aimĀ for? For this I usually conduct a ātime-machineā exerciseāāāthis exercise, which has many variations so pick whichever one resonates with the group, involves the team brainstorming what a future ideal future looks like in detail., Can be 6, 12, or 24 months or longer, doesnāt matterāāāas long as itās significantly longer than your iteration period length. The purpose is to lift the team's gaze to a longer horizon to combat the potential incrementalism many successive safe choices can result in.
Review two scenariosāāālong-term pace vs short-termĀ pace
As I mentioned, I talk through the above diagramāāāoften drawing it on a whiteboard with the team present. I also cover this topic in presentations to the wider group for repetition and reinforcement as I have been mostly been working in distributed work environments for the past decade.
For some more thoughts on how to reinforce learning and improve alignment here is my post on organisational communications planning:
I establish the two axesāāāone is time, focusing on how time progresses through work done in iterations. I have represented the iterations in the diagram in blue. You could label The Y-axis I labelled āimpactā as value or other variations (be careful not to swap an outcome for an output!). Even better is getting even more specific about what is important to your business.
Maybe itās the downtime customer experience you want to improve, the number of failures customerās experience, or any of a myriad of customer-facing aspects you want to improve. If youāve noticed fairly flat progress for many months when there is ample improvement, select what matters most to improve significantly for your business. The pathway to improvement may not be evident to the team but that the current situation is not ideal is likely to be something they are more aware of. Finding examples that resonate is essential.
When agile practices such as scrum are adopted across a software product development organisation, it can sometimes be assumed that success is rushing to get as much done as possible. There can be the cognitive dissonance of knowing that there are significant quality and productivity issues, but the team feels they have done what they believe is expected of them by having another very busy sprint.
For this scenario, there is a line for the average velocity (lead time or another measure of the teamās progress towards the value they create). The red meandering line represents how progress towards impact occursāāāsometimes we are improving, often we are trying things that arenāt working and need to pivot, and sometimes we make a situation worse. All this is fine as long as we are measuring the right things, being disciplined in the options taken, interpreting results, taking in new information, and adapting to new information.
In contrast, the diagram also features two linesā one straight representing a steeper improvement trajectory and a green meandering line. For the second scenario, a team selects from a wider range of activities that could progress them towards their chosen outcome. This wider frame of options is the result of a team choosing not just options that have an output that can be completed in an iteration or less but also include options that may pay off over a longer period (i.e. over two or more iterations).
For more on how to structure a workshop that can help a team formulate a shared view of the future, you can see the following post:
How do we support the team in a longerĀ view?
With the context of goals of different timescales established by the team in the above workshops, the team can see trade-offs more clearly now and in the future. Combined with measures on which they track regular progress, there are now more signals on whether the movement is forward, in place or backward. If the team responds and adapts to these, then the chance we are finding the improvement path increases. These information assets must be established as goals and success measures that remain visible to the team and tracked.
Encourage the team to periodically refresh by repeating the workshop or selecting other methods that can help them achieve the same clear view of the desired future. Without these, there can be endless tweaking without even being in the right territory of addressing what may be holding them back.
This is especially true if the feeling that rushing to complete the safest task next sprint is the only option that the company will accept. Leaders need to be explicit with the team that the outcomes that improve the customer experience over the long term and their velocity over the long term are what the organisation values. This requires regular repetition because other gravities in your organisation may be working against you as I describe in this post:
I have resisted being too prescriptive in this post, as there is no single best set of practices to navigate thisāthere are many choices that will serve the purpose. What I have focused on is highlighting the concepts and elements that are essential to be addressed. Every teamās context is different, so there will be options that better suit different teams. Also, it can be good to switch up the approach to the workshop to avoid such practices becoming stale.
Have you used any of the above approaches at your organisation? Did you have success? What else works for you? Anything you suggest should be done differently for even better success? Sound off in the commentsāāāyour feedback is helpful, and as these posts are living documents, I will incorporate improvements to them over time such that this is the best possible reference it can be.
If you like this post, it would be great to get your feedback in a comment and/or by clicking ā¤ at the bottom. This feedback gives the author warm and fuzzy feelings.