The problem with sprint retrospective meetings is that too often they are kept only because they are "required" by Scrum. If that is the case in your organization, you are probably feeling that sprint retrospective meetings are a waste of time. If I would be in your shoes, I would feel the same way.
I have written about sprint retrospective meetings before but after I read the book Implementing Lean Software Development - From Concept to Cash I realized that my advice was perhaps a bit too abstract. In reality, the solution for transforming useless meetings to productive ones is quite simple. All you have to do is to ask one simple question:
What is our biggest problem and what we are going to do about it?
There are two reasons why this simple question is such a powerful tool for identifying problems:
- It is concrete. If you ask concrete questions, you will get concrete answers. This means that the answers will identify the biggest problems which team members face in their every day work. Finding and solving these problems is important because it ensures that the members of your team can spend more of their valuable time for productive work. In other words, they can provide more value to the customer. Also, asking this question should protect you from hearing process specific mumbo jambo which does not identify the real problems or help you to solve them.
- It calls for action. Call for action is important because it reminds you that there is always room for improvement. It is very easy to fool yourself to believe that the status quo is as good as it is going to get (especially if you have been using agile software development methods for a while). Obviously, this is never the truth. However, as long as you keep asking that simple question, you will remind both yourself and your team members about one of most fundamental principles of agile software development: continuous improvement.
After you have identified your biggest problems and decided what to do about them, you must ensure that the problem are actually solved. I have written earlier that a good way to ensure this is to select a suitable team member who is responsible of solving the problem during the next sprint. The next question is:
How to select that team member?
I believe that a passion for a cause can help a person to achieve remarkable results. It is also very likely that the team member who pointed out a specific problem has a passionate attitude towards that problem. Therefore, in my opinion the best person for dealing with a specific problem is the one who pointed that problem out in the first place. He has the motivation and the knowledge needed to solve his problem. Let him use that motivation and let him feel proud of his work.
If you want to remember only one thing about this blog entry, it should be this:
If you let your team members to solve their own problems, you will get concrete solutions for concrete problems. On the other hand, if you decide to form a (management) committee to solve the problems of your team, you will end up with an abstract process description which is followed by no one. I don't know about you, but I will take the first option any time.