Or “How do we have a proactive (as opposed to reactive) retrospective?”
Or “How do we increase the effectiveness of the Retrospective?”
Or “How do we stop fluffy retrospectives?”
We’ve kicked off the Teams (and Trains) in their new alignment with the expectation that they will work to improve the flow of value based on the value streams identified. Instead, what we find is that in an effort to get control of the work, the Teams stay very much in a “business as usual” mode. Some of this is caused by falling back into old habits (“I know how to do this work in the ticketing system”). Some of this is caused by a lack of direction from leadership (“We don’t have the Features coming in to the Teams that reflect the new, expected work”, or “We have not talked about how much capacity we want to be allocated to new work versus the ticketing system and what the leadership is going to do to help protect the Teams from using more of their capacity for ticketing items”).
And some of this is caused the inability of the Team to really work toward increasing value delivery. If we assume that we have addressed the other issues, this issue remains. How do we help Teams step away from business as usual? You would think that a Retrospective would help the process, but too often these become reactive as well, almost rote, focusing on small changes as a result of things that were noticed in the last iteration.
Another way of asking this question therefore is “how do we increase the effectiveness of the Retrospective”.
A lot has been written about ways to improve retrospectives generically, including information of activities you can run to improve engagement, structure of the retrospective so that you are working real problems, and so on. All of these are aimed at seeing what went wrong in the past, working to understand root cause, working to determine how to address and then specifics about we create and experiment and implement a change.
Notice, however, this is often a backward looking exercise. While there is no doubt this is useful in a lot of instances, the viewpoint suffers in that we are not really developing the future. This approach makes sense when incremental changes to existing ways of thinking, existing processes, Team dynamics, etc will result in significant improvements value delivery. In the case of the Team working tickets, you will end up with a better response to the tickets coming in. But since there is always more demand (tickets coming in) than capacity to deal with it, these improvements will be “sucked up” by the extra tickets the Team can now work.
What if we need a more significant change than this incremental approach?
In this case, we need to have the Team step back a little and change their thinking, to be less satisfied with the current status quo and have a more proactive approach to their work. Instead of the standard retrospective meeting, we should work one aimed at improving the future; a proactive retrospective, if you like.
What form does this take?
One thing that you can do is change the activities so they are a little more proactive. For example, instead of having an activity that looks at “what has happened” we look at impediments from a different perspective:
(Note: I am indebted to "Little Book of Impediments" by Tom Perry for this list.)
In many ways, this thinking approach is really about increasingly seeing the whole system, seeing the Team’s part in that system, and seeing where the problems and impediments are. Once we have identified the problems, the usual Retrospective steps apply - root cause analysis, ideas to address, plan of action (including backlog items and experiment), then review results at next Retrospective.
As a side note, Teams that do this kind of retrospective will report that there is a big increase in the level of discussion and engagement from Team Members as they discuss what might be. And so while you might not do this type of retrospective every time, it can be used to really re-engage the Team in improving how they work.
As mentioned at the beginning, there are a number of reasons that explain why people continue in a “business as usual” mode. Some of this is a result of leadership, and perhaps some of it cannot be immediately addressed by leadership. But if you encourage a Team to do this kind of thinking then you must also provide support to the Team when they come with ideas on how to improve.
This means that leadership not only sounds supportive, but also that they provide real support. In many cases this means leadership needs to protect the Team’s use of capacity to improve. In a practical sense, leadership needs to stand up for the Team when a customer of the Team is asking for a faster response to an issue in the ticket system. Remember that things will not change until Teams get to invest in improvements - leadership helps make this possible.