The Team did a fantastic demo. Everything worked flawlessly, even that mocked up user interface that clearly showed that hidden feature. The audience seemed to understand the features shown, and approve of them–there even was a round of applause after the demo. The developers walk back to the team room with big smiles on their faces.
“Do we have a retrospective now?”
“Why have a retrospective? Everything went right, didn’t it? No need to discuss what went wrong when everything went right!”
A long time ago in my company, when we were still making software for other companies, we had a disastrous project. Deadlines were not met, the software had lots of bugs, the customer was unhappy, and we had to spend a lot of time and money to set it all straight again.
After everything was over, the customer was happy again and the developers had had some sleep, we decided to do a post mortem meeting: we sat down with all the people involved, trying to find out where we went wrong and how we could prevent this from happening the next time. After all, we hadn’t enjoyed the experience and would rather learn from it than live it again.
During the meeting, it was proven that hindsight is always 20/20: it was easy to point out wrong decisions, bad timing and coincidences that could have been prevented. So at a certain moment someone said: “why didn’t we do this earlier?”
Henrik Kniberg writes in Scrum and XP from the Trenches: “The most important thing about retrospectives is to make sure they happen.” And they shouldn’t happen when it is too late; they should happen regularly. There are at least three reasons to have retrospectives: to celebrate, to learn, and to improve.
Learn from the Past
The retrospective was skipped, and The Team happily started a new sprint. Again, they successfully delivered. Well, most of it. But the next sprint didn’t go so well. The one after that was even worse.
Sam, the tester, was annoyed because his tests kept breaking because of architectural changes. Ben was sitting in a corner working on his own stuff. Peter was picking up all the bugs and production issues that popped up. Jennifer didn’t want to pair with Bob, because they didn’t get along very well. Stories on the Scrum board were re-written by the team members working on it, without discussion.
The list was endless. Not only were bad practices introduced over time, but good practices had been dropped as well. And nobody had noticed…
To learn from the past, you have to go over it, and think about it. The retrospective offers you an opportunity to do just that.
Even if everything went well, it is worth thinking about: why did it go well? How can we repeat this success? So don’t skip a retrospective because you’re mostly happy about the last sprint. Good habits will be lost, and bad habits will build up; long-time habits are much more difficult to fix.
The retrospective is an opportunity for celebrating after a successful sprint. It will make you feel up and ready for the next sprint. It doesn’t have to be a full party with drinks, food, and music (although some cookies with the coffee may be nice) but patting yourselves on the back and congratulating each other with a successful demo is a good thing. Ideally, the retrospective is on the same day as the demo, to conclude the sprint looking back; then have the next sprint planning meeting the next (business) day, to start the new sprint looking forward. Having all three meetings on the same day can be done, but is a hard day of work.
Avoid Problems You Had
The obvious things to discuss in a retrospective meeting are: what went wrong? What can we improve in the next sprint? But don’t restrict yourselves to code-related issues. Think about the stand-up meetings, the demo, the releases (if any), distractions, availability of machines, stickies, white boards, the communication in the team–this is your opportunity to talk about anything that you didn’t like this sprint.
One goal of retrospectives is to improve the things that didn’t go well. To improve them, you first have to get them on the table. So name them, list them, and make sure everything that wasn’t good is mentioned.
No Blaming or Fingerpointing
Try to refrain from blaming or fingerpointing. Say “the Scrum board is falling apart” instead of “you promised to arrange for a new Scrum board.” Say “I feel I don’t get a lot of help;” don’t say “I didn’t finish it because you didn’t answer my questions.” Blaming people may make them feel bad and will probably make them act defensively, and then the discussion moves away from finding a solution to finding out who was at fault.
Try to see things as a team responsibility. By all means, mention what is wrong, but don’t assume someone else should have fixed it. Try to explore the reason why it went wrong, instead of assuming you know already.
Taking the blame is another thing altogether. Saying “yes, that was my fault, I’ll fix it.” is clearly a good thing to do.
Repeat What You Did Right
What goes for problems also goes for good things: you have to identify them to be able to benefit from them again. So it is equally important to make a list of things that went well during the last sprint as it is to make the list of problems; it will be much easier to stick to them. And sticking to good habits is probably even more effective than trying to improve on bad habits.
Apart from that, what is a very good thing to some people might be a very casual thing for others. You might have forgotten you drew a quick diagram on the whiteboard that day, but someone else might mention it as a very good thing. That would be a good reason to draw more diagrams.
Last but not least: it feels good to make a list of good things. It is part of celebrating a successful sprint. That alone is a good reason to do it.
Every Beginning Is Difficult
The Team is sitting in the room for their first retrospective. As nobody knows what to say, the Scrum Master begins.
“So it all went pretty well, didn’t it?”
Nodding around the table.
“We didn’t really have problems, apart from that story that was much more difficult than we expected?”
“Well, let’s call it a day then.”
Does this retrospective meeting look familiar? Retrospective meetings are actually quite hard. For most people, they are unfamiliar territory, because you are talking about the process instead of about the work itself.
But I Don’t Like Retrospectives!
Retrospective meetings can be pretty boring in the beginning, as nobody knows what to say. The team members might be too polite, not mentioning problems in an attempt to not offend anyone. And since nobody knows yet what is effective in retrospectives, the meeting might be over very soon.
The opposite usually comes later: endless ranting about how bad it all was, lots of discussion, and possibly lots of blaming and fingerpointing. Some retrospective don’t seem to end. The team comes out of the room exhausted, annoyed, and certainly not looking forward to the next sprint. They’re not eager to have another retrospective meeting soon.
Still, a lot of good things are happening in those retrospectives. If you have a boring retrospective, things are going reasonably well. If you have a very heated retrospective, at least you find out the team is not very happy. The key to getting something out of retrospectives is to realize you always learn something from them. Try to list the things you learned at the end of the retrospective, to end on a slightly happier note.
Forming, Storming, Norming, Performing
In his articles about group development, Developmental Sequence in Small Groups and Stages of Small Group Development Revisited, Bruce Tuckman described four stages of group behavior: forming, storming, norming and performing (and a fifth one, adjourning.) The idea is that a group goes through those stages in that order. First they get to know each other (forming); then they go through conflict, discussions, and competition when their personalities clash (storming). If they get through this stage, they will settle on the “rules” of the group (norming), after which they can really perform as a team.
The important thing to realize is that to get to norming and performing, you have to go through the storming phase. The worst thing a team can do is to suppress all unpleasant thoughts and gripes they have about team performance, as it will never get them through to the next stage.
Retrospective meetings are a very good tool to bring out the best in teams, as it will more or less force them to talk about how they work together. This will make it much easier to go through all the stages. Compared to teams that never look back, you will see the team spirit grow much faster.
Just the Team
Retrospectives are for the team only. The stand-up is open for everyone (although they may need to remain silent). The sprint planning is equally open (although nobody may want to attend it apart from the team) and the sprint demo is actually meant for everybody outside the team, but the retrospective is not. Team members will never speak freely if managers or stakeholders are around.
The Scrum Master is of course part of the team. If the team has a dedicated Product Owner (which it really should have!) he or she is also part of the team. Business owners, product managers, or stakeholders aren’t.
Get It on the Table
Jenny had prepared for the meeting very well. She had a notebook full of notes with her, and when the meeting started, she took the floor.
“Right. First of all, I must say that pair programming really doesn’t work for me. I mean, I tried to do it twice with Greg, but he just types too slow and does everything with the mouse. Then I think we should have prepared the story about the database model a lot better. I mean, we must have changed it four times or so? And… no, let me finish, the user interface story was not better, because…”
In a retrospective, it is vital that everybody gets their say. Each team member may have a different opinion about what was good or not so good, so everybody must get the opportunity to speak.
But some people are better speakers than others; some like talking, and some don’t. To make sure those don’t drown out the others, there are some simple methods to try in retrospectives.
Do the Rounds
An easy way to do a retrospective is to go around the table and let every team member say one, and not more than one, thing that went well. You may pass if you cannot think of any. The Scrum Master (or someone else) writes them on yellow stickies and sticks them to the wall where everyone can see them. After a full round of passes, go around the table and let every team member say one, and not more than one, problem in the sprint, until everyone passes. Stick them to the wall also. Pick a few items that need further discussion, preferably not more than three, and come up with some very easy, actionable ways to improve.
The advantage of going round the table this way is that every team member gets their say. It is not that the first speaker is stealing all the issues. It probably still is a good idea to make the loudest team member go last.
You can also go over the sprint in chronological order. Draw a timeline on a whiteboard, start at the beginning, and write good things that happened above the line and the problems below it. Then decide which items need more discussion.
Add the burn-down chart to the timeline, if that helps the team. Also bank holidays, releases performed, and other events can be added to the timeline. The timeline helps you to remember things, and to make sure quiet team members get their say.
If you have created a list of things that went well, and a list of problems you encountered, it is time to discuss. If it is not obvious which items to discuss further, you can do dot voting: using a marker, every team member can put three dots on items, possibly all three on one. The items with the most dots win.
Don’t do dot voting if there are only a few items to discuss, and weed out the improvements that are blindly obvious (like “better handwriting on stickies” or “be on time in retrospective meeting”). For this type of improvements there is only one advice: just do it.
Writing in Groups
One more method for listing things that went well and problems encountered in a retrospective meeting is writing in groups. Split the team up in groups of two or three, and let every group write a bunch of yellow stickies with good things and problems, for about ten minutes. Then each group in turn puts the stickies on the wall, putting the ones that are the same (or very strongly related) together.
One advantage of this is that it is instantly clear which items deserve more discussion: they form the largest groups of stickies on the wall.
Inspect and Adapt
“Guys, time is up. Here is the list of problems; Gary, can you hand me the good things? Thanks.”
“But what do we do with these lists?”
Listing problems doesn’t make them go away. Although it is important to get everything on the table, it is equally important to analyse the lists. In the end, you want some action items that will improve your next sprint.
It is important to discuss items a bit further. The aim is to find out why things went well, or why things didn’t go that well. The real why might be hidden deep under the surface. The trick is to dig down deep enough that you can find it.
Take a simple example: the most important story was not finished. There is one task belonging to that story that was in progress for the entire sprint. Why was that? It turns out that Dick, who worked on it, moved on to another task. Why was that? Because he was the expert on that subject, and somebody asked for his help. And why didn’t another team member pick it up, then? Because Dick didn’t check in the code he had written so far.
Now we move from “the most important story wasn’t finished” to “abandoned tasks can be hard to pick up,” which is a lot easier to fix. Several solutions spring to mind:
- Never abandon a task.
- Always hand over tasks explicitly to someone else.
- Go over all tasks in progress during the stand-up to make sure progress is made.
- Always check in code, even if it breaks the build.
Whether these solutions are good remains to be seen, but they are much easier to do than “try to finish the most important story.”
This method of digging down is know as the five whys, because it takes about five times asking “why” to get to the bottom. There are more ways to dig down, of course. The most important thing is that you do it. Try to go from a big and fuzzy problem to a small and clear one.
Retrospective meetings should result in three or four improvement items, or good resolutions for the next sprint. These items should be as specific as possible. Not “do more pair programming,” but “John should always pair up.” Don’t say “try to talk more to the team,” rather say “never move stickies in stand-up meetings.” More specific is easier to do, and it is easier to see that you’ve really done it. And once you have done it for a full sprint, it will have become a habit.
Don’t be afraid to have strange improvement items, like “hide stories we’re not working on.” If it works for you, it’s good. Also don’t be afraid of improvements that are the direct opposite of earlier improvements, like “put all stories for this and the next sprint on the board.” Teams change, people learn, and if you decide that it works for you, it’s good.
Try to stay away from placing problems outside your team. “We didn’t finish stories because there was too much unplanned work. That was not our fault.” You still can do something to improve the situation. For example, take in less work, and make sure you do finish that. Of course it is a good idea to talk to the people that brought in all the unplanned work, too. But don’t get trapped in the idea that it is all someone else’s fault. Even if this is true, you can try to improve in handling it.
Deciding on improvement items is probably the most important part of the retrospective meeting. Here the team is agreeing on the things that will make the next sprint better. The team should reach consensus about those items, i.e. they should all agree that these items are the most worthwhile things to try in the next sprint.
You don’t reach consensus by democracy, so don’t use dot voting for this. You reach consensus only if every team member agrees that this is the best way for the team to go. If someone is really against it, you probably shouldn’t do it. If someone really wants something, it’s probably worth trying. This is not about the majority rule over the minority; this is about the whole team agreeing.
To reach consensus every team member needs to be open-minded, cooperative, and work towards a solution. Be patient. It can take a long time to reach consensus.
Why is team consensus so important? Because the team as a whole needs to actually do the things that were decided. If some members don’t believe in it, they will not do it. If some team members don’t do it, it probably won’t work. And then the whole exercise was for nothing.
Retrospectives: Getting It Right
So The Team did a fantastic demo. Everything worked flawlessly, even that mocked up user interface that clearly showed that hidden feature. The audience seemed to understand the features shown, and approve of them–there even was a round of applause after the demo. The developers walk back to the team room with big smiles on their faces.
“The best thing this sprint really was how you and Jen mocked up that interface. That was such a smart way to demo the feature!”
“But to get the story finished to begin with! I never thought we could do that.”
“I think this was the best sprint we had so far.”
“What a sec, guys. Did you start the retrospective already?”
If your retrospectives are not effective, settle on some simple and playful methods to get the information on the table:
- Celebrate the end of the sprint. Bring cookies to make sure everybody comes!
- Try Do the Rounds, Timeline Lists or Writing in Groups.
- Use the Five Whys to dig down.
Then come up with some simple, physical improvements. For example, make some changes on the Scrum board. Don’t try to solve all problems at once. Settle on some simple solutions for small improvements, and take the time to make them work out.
Retrospectives can be scary, because it forces the team to talk about the process (and emotions and relationships) instead of work and code. And retrospective are difficult, as it can be hard to solve the problems found. Then they can also be boring, when no one knows what to say. So start small. Make it easy. Many small changes can create big improvements.
Retrospectives are very important for team improvement. You cannot look forward all the time; sometimes you have to look back, and learn. If your retrospectives are done honestly, seriously and consistently, the team will improve. And that is what Scrum is all about.