Many people dislike the 3 question, plus-minus-delta retrospective. I am one of them. The plus-minus-delta agile retrospective leads to many problems. I say it was never the “standard” in the title, so why are so many people confused? Or…am I the one confused?
While co-coaching recently, the other coach and I had a brief exchange about how the “standard” agile retrospective was not good. I was a little confused, since while I certainly do not always use ‘the standard’ or baseline agile retrospective, there is value to it — at least I thought so? The baseline retrospective I employ is a solid method to teach people how to do an agile retrospective. I asked a few more questions and realized that while we were both using the term “standard retrospective,” we had different definitions of the term.
This is part of the ongoing series of articles on retrospectives. I will be sending out an free eBook with all of the articles to any email subscribers, if you are interested.
What is the Plus-Minus-Delta Agile Retrospective?
Given the confusion on the subject, let me define an agile retrospective format you should NOT use, the Plus-Minus-Delta Agile Retrospective:
- What went well?
- What did not go well?
- What can you change?
Agile Retrospective Confusion
Perhaps I’m the only one confused, but many seem to be of the opinion that the standard retrospective is what people unaffectionately refer to as Plus-Minus-Delta. What are the positives, what are the negatives, and what are the changes? I agree with the prevailing wisdom on the subject: don’t use this method. So why the confusion? Mine stems from my misunderstanding that plus-minus-delta was “the standard”; I guess I missed that memo… errr… email… uhhh…. tweet.
You do want the team to dig into information that can look a bit like those three questions. It might seem like it can work and some have used this successfully. I actually thought I was one of those people; however, I realized that the times that I had used it successfully, it was because I was breaking question 3 into a number of additional questions and steps. Since it is not “indicated” in the format, many people skip over these “hidden” questions. Further, even if the intent was to ask more than the 3 questions, once you state there are 3 questions, many people will stop there.
Where Did the Idea Come From?
As I did some research, I realized I must have either missed or ignored a lot of writing on this topic. There are many articles by agile folks who talk about the 3 question, plus-minus-delta retrospective. So I can understand why so many use this and/or think it is “the standard.” While I considered including links to a few of the articles here, I don’t believe the benefit outweighs possible negatives. I did find it interesting that in a number of the posts that started out talking about ‘Plus-Minus-Delta’, they went beyond the 3 questions (a good thing). This supports the idea even when people use the name ‘Plus-Minus-Delta Agile Retrospective’, the intent is go beyond 3 questions. As I noted above, I like the term baseline rather than standard since the word ‘standard’ carries extra weight and implications. A baseline is merely something to build on.
I became curious if I had missed something in the old Scrum Guides, so I checked past versions of the Scrum Guide. The current version is now available at www.scrumguides.org, a joint effort by the Scrum Alliance and Scrum.org. I looked at the 2011, 2010, and 2009 (first Scrum Alliance version) versions, and it does not indicate any specific sprint retrospective format.
Going back to Agile Project Management with Scrum (2004), Ken Schwaber notes the idea of asking lists 2 questions: 1. what went well during the last sprint and 2. what could be improved? However, he goes on to note that the team would prioritize (rank) the items, discusses actionable items, and more! It seems quite clear to me that there is more to the process than just a few questions.
What’s Really Wrong with Plus-Minus-Delta?
Whatever the source, it is clear that it does not work well. There is a long list of reasons people don’t like this overly simplistic retrospective, and I’ll cover a few of my top reasons. Feel free to send me others or comment if I did not cover your top reasons!
Reasons Not to Use Plus-Minus-Delta Agile Retrospectives:
A. They quickly (even the first time) sound like status meetings as someone goes around the room and asks for each person’s contribution to the list.
B. The list of ideas for possible changes (what question #3 should be) becomes “all the things that MUST change.” This can happen very quickly when someone attempts to drive the team to do agile (obviously not recommended!). The team will just check-out.
I see all of these as being quite related and could probably be boiled down to destroying team spirit. This occurs most often when there is a person assigned to manage the team and the team is not responsible or accountable to improve, learn, or deliver results. The retrospective turns into a time to track the team, hold them accountable, and drive them to improve…this is making my stomach turn just typing it.
The list of change ideas or improvement ideas tends to get converted to a big list that is tracked and reviewed. The team did not commit to these ideas, so why are we tracking them? I have seen lists in the hundreds.
In one case folks had a stage associated with each change idea saved on an intranet. I was very confused–a stage??? Then I realized this was the intranet site from an old “lessons-learned” waterfall approach that had been renamed to agile retrospectives on the intranet. While well-meaning, this is what occurs when agile turns into only a process or framework.
C. They get boring fast. Once people start to believe this is “the standard,” it gets boring.
D. They prevent collaboration and discussion by over-simplifying the goal. The goal is NOT to generate a list of crap. The goal is to have discussions, celebrate, collaborate, learn, and look to how the team can improve itself.
E. There are so many AWESOME ways to facilitate a retrospective! If you are looking for inspiration, visit Agile Retrospective Resources for articles, websites, and books to learn even more about retrospectives!
Change It Up!
Maybe you have been using this format and it hasn’t been working. Maybe, despite the issues, you think it is working. Either way, change it up! Try new formats and focus on getting to the core value of what agile retrospectives are about! Check out Agile Retrospective Resources for ideas or make up your own. The Real Baseline Agile Retrospective Format looks at this topic from the point-of-view of a better baseline to use.
There are tons of options out there to find new ways to make your agile retrospectives better, more fun, and more interesting!
To address B, many teams start using dot voting. So it’s plus-minus-delta-dot vote. Sigh.
D is important. I’ve seen team members walk into a retrospective with heads full of ideas to write down, and the rest of the retrospective seems like a waste of their time because they know what to expect. They don’t spend enough time listening to their teammates’ perspectives of the sprint to identify real problems and possible actions.
Allison, I agree, it is like “let’s check everything off the list” and then we are done! On the dot voting, it is interesting, there are so many subtle variations we see on this approach, but like you say, when people are not listening the value is gone!
If I’ve seen a standard, it’s closer to PLUS – MINUS – DOT VOTING – WORK ON THE HIGHEST VOTED ITEMS. It’s not about what we can change, but what is our biggest issue.
I totally agree with the idea that repeating the same process ad-nauseam leads to teams checking out. One of the easiest way to change things up is to change the host of each retrospective. It drives me a bit crazy when I hear the scrum master always leads the retrospective.
My current favorite style for a retrospective is based on this post: http://www.scurri.co.uk/blog/running-retrospectives/
Jeffrey, Thanks for your comment! The post you mention starts with a 3 question retro in 30 minutes. Perhaps for a very mature and great team that may work sometimes, but again all of the cautions above apply. I still don’t see a commitment by the team in that approach. They also mention giving the index cards out 30 minutes ahead of time. I’d prefer the team be together for the entire time (is it 30 or 60 minutes?).
I assume the one you like is starfish. I like that one as well. In that post, I’m left wondering if the intention is to do starfish in 30 minutes. I’m not sure how that is enough time to celebrate, learn, improve their relationship, and explore ideas to take action on. Certainly the context is important — team size, type of organization, and background of the team are all factors. I’d note that I’m one of those people who thinks 30 minutes is too short in *most* cases for a (2 week) sprint retrospective.
Great post, Jake. In my opinion, this is only one of the symptoms from when someone follows agile as a methodology, rather than as a foundational set of values. Most likely, they’re doing what they were showed once, and now repeat it without fully understanding why it’s being done.
Your line “while I considered including links to a few of the articles here, I don’t believe the benefit outweighs possible negatives” is hilarious!
On the last project I worked on, the team loved the retrospectives because each one was different, and they never knew exactly what to expect before the meeting. It kept the discussion lively, fresh, engaging… And, kept the communication and discussions the focus of that time.
Jeff, thanks. I agree, one of the challenges when teaching focuses only on agile practices, is lack of understanding the intent! They miss the idea of celebration, the learning, and building a better team relationship! Glad to hear your last team loved the the retros! Always nice to hear the good stories!
I can fully understand why you dislike to have a standard way of doing retrospectives. Teams differ as do the issues and circumstances that they have to deal with.
There simply is no silver bullit retrospectives. In stead there are many useful exercises. It takes some skills and guts to do them, but you will be rewarded with actions that teams do to really improve and deliver more value.
@BenLinders
Co-author of Getting Value out of Agile Retrospectives
Ben, thanks for your comment. I agree with your point on the skills and guts! That often makes the difference in how valuable the retrospective is to the team. I think anytime there is a “standard” is gets overused, although my primary issue with the plus-minus-delta as a “standard”, is that it does not even include all of the important elements. I’m curious to check out your book as well.
[Updated] I downloaded your book, thanks! Good stuff there! I like this (among other things):
“Agile retrospectives give the power to the team, where
it belongs! When the team members feel empowered, there is
more buy-in from the group to do the actions which leads to less
resistance to the changes identified as necessary by the actions
coming out of a retrospective.
Another benefit is that the team both agrees upon actions in a
retrospective and carries them out. There is no handover; the team
drives its own actions!”
It captures what we are aiming for and also points to what does not happen when it gets it turned into a list generating exercise. The business value section of the book also hit a lot of great points!
I have added the book to the Agile Retrospective Resources article I have with a link (check out that link or go direct to Leanpub to see more about or purchase Getting Value Out of Agile Retrospectives if you are interested).