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.
Good points! I believe that retrospectives often lack focus. The team develops a laundry list of problems and has trouble focusing on any one problem and getting it solved. Asking a simple question around the "biggest problem" will generate thoughtful debate. Assigning that problem to a point person also helps.
If the team is doing retrospectives after every sprint, they will solve many problems over the course of a project. Keep it simple and you'll get more done!
Vin, thanks for your comment.
I totally agree with you. The lack of focus might also cause an another problem: The members of the team might concentrate on problems which they "cannot" solve. They might for instance start to blame management and so on. It might be true that the management has made mistakes or that the management sucks. However, the team should concentrate on problems which they can solve because that is the only way to improve their every day work.
I have also got a feeling that the books and training about agile software development might actually cause more problems than they solve. Very often they give an abstract and a kind of fancy description about agile software development. I believe that this is a very harmful approach because it might makes people feel that their problems are not "good enough". Thus, these people keep their mouth shut during a retrospective meeting.