I’m starting with an assumption: that we believe there is always the need for improvement (in what you produce and/or how you make it). If your product/team/system is perfect then you can stop reading now and go feed your unicorns instead. 😉
The next group I’ll invite to stop reading are those who believe it’s everyone else who needs to change but not themselves. I have worked for organisations where senior/middle managers want the coaches to “fix” the teams. Unfortunately, there can be no significant improvement until those people realise they’re not just part of the solution, there’s a good chance they’re actually part of the problem.
Hopefully, we are agreed on the need to continuously improve, and to be part of those changes. So how are you demonstrating that? Do you make sure there’s time for experiments or do you constantly push for more output? Do you encourage the team to discuss frustrations even when that might lead to questions about the organisation’s structure or decisions that have been made higher up the org chart? Do you help the team look deeply at themselves too, because effective retrospection and root cause analysis is not easy?
One unfortunate anti-pattern I’ve seen is “we’re too busy to improve”. This may be understandable for a week or two, but when this persists then it’s a red flag. I’ve encountered variations of “the Product team want us to focus solely on delivery”, or “leave the teams to get their work done”, or even “if it doesn’t help us get stuff done then we don’t have time to look at it”.
This is a very short-sighted approach; I’ve seen it paired with cancelling vacation or requiring overtime. The focus becomes the quantity of output, often at the expense of quality, sustainability, and the team’s health. Sadly the eventual outcome is often the realisation that what was produced wasn’t even all that important or urgent.
Returning to the presumed assumption that time spent on improvements will not contribute to helping the team deliver more, it’s important to ask why. If the time spent on retrospectives each sprint (commonly that’s 1 hour every 2 weeks) cannot be spared, then your plan is already incredibly fragile and very likely will fail – how will you cope if a team member is sick for a day, for example.
So rather than focus on the cost of improvement, think about the potential benefits. What if that one-hour retro resulted in an improvement that saves the team a few hours? What if the retro highlighted a concern about the quality or design of the work they’re producing? What if the conversation resulted in the discovery that a critical element had been skipped due to cutting corners because they are under pressure?
Saying “we’re too busy to improve” is a step back towards waterfall; it sends the message that “we know everything we need to know” and that nothing can be learned from the work the team are doing. More damagingly, if that is believed to be true when under pressure, when it’s finally lifted why would the team return to doing retrospectives and looking for improvements?