I have noticed that human beings are very solution-oriented. When we see a problem we immediately try to find a solution. Perhaps we have recently read a book or an article that comes with examples of good solutions and now we see a chance to apply it. Or perhaps we are clever enough to come up with a solution ourselves.

Not that seldom we have a solution ready even before we understand the problem. It's a nice solution and we are eager to apply it. So now we start looking for problems that the solution solves...

Or perhaps we truly understand the problem. Perhaps we actually do start with the problem and try to find a solution for it. However, when we find that solution we go back to our instincts and can't wait to start using our solution. Seldom do we care to find out if it is the only solution and even less if it is the best solution.

I see this happen in every Retrospective Session I attend to for almost all issues discussed. And I have obviously been guilty of doing it myself many times.

Since it's such a common behavior, almost like an instinct, there's no point in trying to change people. Instead the focus must be on controlling it. My trick is to change the goal of the session:

The Retrospective should be about finding problems, not solutions.

You should not even be allowed to come up with solutions in the Retrospective. If anyone mentions a possible solution, the facilitator should interrupt and steer the focus back to problem solving. Not even the last five minutes should be about solutions. The solving part should be handled elsewhere.

Unfortunately, this is not enough. The solution finding instincts can haunt you even though solutions are banned. The next dilemma is that usually when people mention problems they are very solution-like. For instance, a problem might be "our team is too big". This is another way of saying "split the team into two", which is a solution.

What you need to do is to locate the symptoms of the problem. Ask, in a reverse 5 whyish way: Why was this a problem? Did the daily synchronization meetings take too long? Was the iteration planning session too long? Was there a lack of team spirit?

If the symptom was that the daily meetings were too long, then perhaps the root cause was that each member talked too much. Or perhaps there were non-team members present talking, taking up time.

If the problem was solved by splitting the team what you've done is merely kill the symptom while the problem still remains. Actually, you've made things even worse since not only does the root problem remain, but you've hidden the symptoms, making it more difficult to fix.

Once you've found the symptoms you can use 5 whys or fishbone diagram to find the root cause.


So when should you do the actual solving?

Most of the time, once you've found a problem the solution is obvious. All you need is to do some small modifications to the problem description and you'll get a solution. Take the "our team is too big" problem as an example.

Sometimes the solution is not that easy to implement though. If we decide to "split the team into two", there will arise questions on how to actually implement this. Who should be in what team? Should we have one or two backlogs? How do we overcome the communication barrier between the teams?

This is a discussion that takes longer than any Retrospective. Also, having the whole team brainstorming answers to these questions is probably not very efficient. Better then to form a small group of people who is assigned the task to think a bit longer about a solution.

But that's a different meeting with a different goal.

Disclaimer: I've impudently stolen the title for this post from Tim Ottinger :)