Dynamic Reteaming, 2nd Edition

Chapter 10. Anti-Patterns

Reteaming does not solve every problem, and it can be done poorly. If you decide you want your teams to be more collaborative and to spread information within the team, and then you force them all to pair program because you read that it’s a good idea, you will probably have a lot of unhappy developers who think that you don’t trust them and that you’ve taken away all of their freedom. I lived that scenario at a company. A similar situation is recounted in one of the following anti-pattern sections about trying to reteam in order to share best practices. This is just one example, but my point is that you need to exert great care when practicing dynamic reteaming—especially when you’re doing a larger-scale reteaming that will change an existing dynamic. See Chapter 12 for what to consider when planning a large reteaming initiative.

It is less risky to do a reteaming on the edges, which is when you apply the one-by-one or switching pattern, for example, and you aren’t disrupting the entire dynamic as dramatically as if you were to, let’s say, split a team in half or take four team members out and put only two back.

I’m not trying to paint a picture in this book that all of this is easy or that dynamic reteaming will solve all of your problems. It depends on what you are trying to do. You can’t make guacamole out of an unripe avocado—sometimes teams and organizations aren’t ready for change. And then sometimes it just happens, like someone leaves and you ...