Happy Friday!

April is such an interesting month. Weather changes for a lot of us, allergies begin to make our lives miserable, school is wrapping up, and taxes are due. It's a month full of transitions.

I hope that's all going well for you.

Speaking of transitions, I wanted to write a bit about teams that get stuck. We might also say they hit a plateau of their capabilities. For teams that utilize retrospectives, they hit a plateau when nothing actionable emerges repeatedly or you see the same few issues over and over.

You might also listen for specific patterns of how the team talks about an issue as well. There are two patterns I wanted to talk through today though. Also, note that these patterns don't exclusively mean people are stuck, but they are a good indicator. The two patterns are:

• Pushing the issue onto someone else
• Inventing obstacles

When I say pushing the obstacles onto someone else what I mean is that when an issue is discussed, the group makes that issue someone else's instead of their own. I'll use an example here from a client where the team discussed pair programming. They made this issue one of their manager. The only way, to their reckoning, that they could sit together was to demand that their manager assign pairs every day. They weren't willing to consider that as a team they could decide that for themselves. Now, some of you might think that they worked with some micromanager, but that couldn't be further from the truth. Instead, the team pushed the issue to someone else and claimed that change was impossible.

Now let's talk about inventing obstacles. This one is more common but more subtle to detect. Software teams are often hardwired to solve problems. That means a lot of their conversation is built around talking about and solving problems. When they invent obstacles, however, they create problems that don't exist, and then refuse to solve them. The tricky thing about this is the words sound the same, but the tone and reaction are different. Healthy problem-solving teams have a tone of generating options to solve a problem. Inventing obstacles has a tone of we can't because of some obstacle.

Let me use another example. The same team I mentioned before discussed pairing again. Only this time they moved from pushing the issue to someone else to inventing obstacles. So, they got stuck with issues like:

• When do we pair?
• Who do we pair with?
• What do we work on when we pair?
• How do we know people paired?

Reading this, it should be pretty clear that none of these are significant issues, but when teams invent obstacles, each one is an unsolvable problem that prevents them from moving forward.

So, when you detect teams using these two patterns, it usually means they're at the horizon of what they know. Be patient with them. Also, I might offer that they aren't likely going to get past this alone. However, if you can pop them out of the rut and get them past the plateau they often see a lot of growth because the horizon has opened up again and there is suddenly lots of room to improve again. A technique to help do this is to reframe and echo back what they're saying. Hearing it from someone else often helps highlight the fact that most of this is invented.

I'd love to know if you've seen a team get stuck like this recently, and have you moved past it?

Sincerely,

Ryan