Long term average pace > short term pace
One of the most common challenges I have coached teams on is on 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 those that are less certain, compound 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, 24 months or longer, doesn’t matter — as long as its significantly longer than your iteration period length. The purpose is to lift the team gaze to a longer horizon to combat the potential incrementalism many successive safe choices can result in.
Review two scenarios — longterm pace vs short term pace
As I mention I talk through the above diagram — often drawing it on a whiteboard with the team present. I also cover in broader group presentations 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. The Y-axis I have labelled ‘impact’, you could label as value or other variations (be careful not to swap an outcome for an output!). Even better is if you get even more specific about what is important to your business. Maybe its downtime customer experience you want to improve, or the number of failures customer’s experience or any of a myriad of customer-facing aspects you want to improve. The main thing is if you’ve noticed fairly flat progress for many months when there is ample improvement to be had to select what matters most to your business to significantly improve. The pathway to improvement may not be obvious 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 what is important.
It can sometimes be an assumption when there has been the adoption of agile practices such as scrum across a software product development organisation 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 feel 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 (or lead time or another measure of the team’s progress towards the value they are creating). The red meandering line is representative of how progress towards impact actually occurs — sometimes we are improving, often we are trying things that aren’t working and need to pivot, sometimes we make a situation worse. All this is fine as long as we are measuring the right things, being disciplined in what we try and how we interpret results and how we take in new information and continue to adapt in response to new information.
For contrast, the diagram also features another two lines — this time one straight representing a steeper improvement trajectory and a green meandering line. For the second scenario where a team is selecting 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 which is choosing not just options that have an output that can be completed in an iteration or less but is including options which 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:
So 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 more clearly trade-offs, now and ongoing. Combined with measures which they are tracking regular progress on, there are now more signals on whether the movement is forward, in place or backwards. If the team is responding and adapting to these then the chance we are finding the improvement path increase. These information assets need to be established as goals and success measures which remain visible to the team and tracked. Encourage the team to periodically refresh through 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 will be accepted by the company. Leaders need to be explicit with the team that the outcomes that improve the customer experience over the longterm and their velocity over the longterm are what the organisation values. This requires regular repetition because there are many other events within organisations and individual biases that can incentivise in the other direction.
I have resisted from being too prescriptive in this post as there is no single best set of practices to navigate this — there are many choices which will be able to serve the purpose. What I have focused on is highlighting the concepts and elements which are essential to be addressed. Every team’s context is different so there will 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.
