User Tools

Site Tools


How Do We Get Away from “Business as Usual” Thinking On Teams?

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

The Proactive 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:

  • Expand scope: Within the Team we have a view of how we deliver our value. But teams often work in a larger ecosystem. With “expand scope” we increase our understanding of the rest of value stream. One way to do this is to look upstream from where we are (“Where did this request come from?”) and downstream (“Who do we provide this to?”) and based on this understanding work to improve the flow of value delivery.
  • Break the rules: All Teams operate in an existing system, with its own rules and governance. With “break the rules” we ask ourselves “Why is process there; does it add value?”. If it does not add value, we work to get rid of the process. If it does provide value, we work to understand how we can make conforming more streamlined. For example, perhaps there is an approval step in our workflow, that we could automatically do with a coded test.
  • Indulge your inner perfectionist: Approach your current process of value delivery from the perspective of “good enough just wont cut it.” Ask yourself “What is the ideal work flow to deliver value and how do we get there?” and then figure out the first step to make it happen. With “indulge your inner perfectionist” while perfect value flow is unattainable, it should offer lots of opportunities for improvements. Many Teams will do a Value Stream Mapping exercise to really understand how value delivery flows, and use the data generated as a result of this activity to improve. But if Value Stream Mapping sounds like something you don’t understand, draw a picture of your process steps to deliver value, from a request to handover to you customer and then write down how long each step takes, how long you spend between steps, and how often (percentage) you do work in each step that comes back because of error. You can expect to see lots of room for improvement (and by the way, you’ve just done your first, basic, value stream map:-))
  • Change your perspective: Your Team doesn’t have to come up with all the improvement ideas themselves. One source of ideas in large organizations is all the other Teams also working to improve. Visit these other Teams to see what you can learn from them. One idea that helps is to invite the Scrum Master from another Team to run your Retrospective. Not only will this freshen up your Retrospective, but the other Scrum Master might see problems and / or solutions that your Team has not worked out yet. Another source of ideas is by changing your role; today you are a Scrum Master, tomorrow a Product Owner, the day after a Team member. As you shift roles, how does the perspective of the issues change. (Note this might not even involve a formal role change; perhaps you just shadow the person in the role). With “change your perspective” you are trying to uncover issues by changing your viewpoint of the system of value delivery.
  • Review your vision and / or goals: Ask yourselves “What is stopping you from get these done?” Again the idea is to step back and see the bigger picture.
  • Speed up: Intentionally speed up process of value delivery so that you make see mistakes that you make as a result. There are lots of ways of doing this. For example, if you are currently on two week iterations, go to one week iterations, or even one day iterations. With “speed up” you use the resultant mistakes you make to understand where the problems are and work to address them.
  • Impediment mining: Become more aware of recurring problems by looking through threads of messages in your email. Or perhaps look at the reasons you are having meetings. With “impediment mining” your email client can be a great source of potential problems with value delivery. Also look at your retrospectives over time. Do you see the same problems come up time and again. Perhaps you should do something about these?

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

Supporting Significant Change

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.

Want To Know More?

/home/hpsamios/ · Last modified: 2023/03/10 07:04 by hans