Test Driven Retrospectives

TL;DR: Retrospectives can lead your team to becoming a powerhouse. One method of ensuring you making real improvements is Test Driven Retrospectives, where you define the desired state during the retrospective. By writing provable statements ahead of working on the task, you ensure everyone has the same understanding and knows what successful change looks like.

—-          —-          —-

A couple weeks ago I attended Gojko Adzic‘s workshop*. He started with an exercise called “Test Driven Learning.” We were asked to write down three questions we hope to have answered by the end of his workshop. After exchanging cards with other people, we became responsible for making sure our peers’ questions were answered over the following three days. I love this idea and the concept alone gave me fresh insights into training and facilitating.

Fast forward a couple weeks to last Friday, when I was asked by a team lead to facilitate their retrospective**. He wanted an outsider to lead the discussion so everyone on the small team could really contribute. After a few minutes, I agreed, but only with a caveat. I’ll only do it if I can preach about the power of retrospectives for a few minutes. I think he was amused when consenting to my plan.

I believe retrospectives are the single best thing about Agile and Scrum. The power of honestly assessing yourself and what you are doing as a team and then working to improve improve yourself, your process, and your output is without peer! Honest and mature teams transform themselves into powerhouses of capability and achievement when they sincerely work this way.

At the agreed upon time I started proclaiming the good news. I talked about the power of retrospectives. I gave the example of a team that transformed itself over the course of 14 months from being stuck to a team releasing valuable functionality every few weeks by working on small, definable tasks they pulled forward, using cards on a public wall. This team still called themselves “waterfall,” but they had added a monthly meeting where they talked about their biggest issue and found a way to work together to solve it. When their biggest issue was solved, they turned to the next issue. In the end they were a group filled with purpose and might because of retrospectives.

Another thing I mentioned was Eliyahu GoldrattsTheory of Constraints. Despite no one knowing about ToC and barely recalling Critical Chain, everyone quickly agreed you make the most significant progress by focusing on the biggest impediment. Tackling anything but the biggest constraint is wasting effort.

And because I had talked about making big differences, one of the categories I asked them to comment on was “What do we need to work on that will allow us to become great?” I labeled this category “GREATNESS.” Other categories were “GOOD / WELL,” for where something had gone well, and “DIDN’T LIKE,” to list minor things that were getting in the way. After briefly discussing all the cards, everyone got two votes for what they thought we should focus on to become a great team. Team members could put them on different or the same card if they wanted.

There was a clear preference for focusing in one area. I confirmed this issue would make the biggest impact on the project, the client, and our goal if it was addressed. Interestingly enough, this feedback item was not an item in the GREAT column. I was satisfied because the verbal and visual influence led everyone to focus on a big, difference-making issue instead of an easy-to-fix item, no matter what column it was found within.

At this point I talked about the power of Gojko’s Test Driven Learning and explained we were going to use this example for the retrospective. We were going to have a Test Driven Retrospective. Now that we had chosen one key item to work on, how would we prove we had accomplished our goal? In the next 20 minutes or so we clarified the goal, spent time individually writing acceptance tests to prove we were making progress, and discussed the tests. We assigned responsibility for completing the goal, and giving updates, if it was still in progress, to one individual.

As a first time exercise, some of the tests were a bit weak and needed rewording. This is to be expected because the exercise was new to everyone. Because of the weakness here, we also assigned a separate team member to work on clarifying what the test should be, better defining success.

The retrospective was just a couple days ago, and the area they chose is going to take some effort over many weeks to really bear fruit. If I get any feedback in the future, I will be sure to post an update for you to read. Without even waiting for the results, I very excited about the possibility this opens and I look forward to trying this again on my own team.


* I’m a big fan of Gojko’s book, Specification by Example and I cite it in pretty much every presentation I give. The workshop was great and lots of learning was had by all. He obviously knows his stuff. Recommended.

** The next book I’m going to start reading is The Retrospective Handbook by fellow ThoughtWorker Pat Kua. In a company of deep thinkers, he’s our expert on retrospectives. With a little luck, maybe he will comment on this idea below.

*** For another look at how a Test Driven Life can lead to increasing success, read Follow the Goal Creep over at 37signals.

“Mastering others is strength. Mastering yourself is true power.” Lao Tzu


  1. Phil   •  

    You’re not too far away from the Improvement Kata – driving improvement by talking about a target state and how to get there rather than a free-form “What does everyone think we should do to improve?”

    One issue with ToC, though, is that it’s kind of like only using ROI to prioritize your features. The size/impact of the constraint is certainly a major factor in choosing what to tackle first, but it’s not the only factor. You also need to consider things like the cost of delay, the value and impact of the improvement, etc. It’s not necessarily waste to work on a smaller constraint.

  2. Amy   •  

    This sounds similar to the Future Backwards Method from Cognitive Edge (cognitive-edge.com). I really appreciate this concept as it will resonate with team members familiar with Test Driven Development. Another of my favorite books on Retrospectives is the classic: Agile Retrospectives: Making Good Teams Great written by Esther Derby and Diana Larsen.

    • Jeffrey   •     Author

      Oo, I have heard good things about Derby & Larsen’s book, but I have not read it. I have a stack of 15-20 books I want to read. The top two spots are filled by Kua and Gojko’s latest book on Impact Mapping.

      Leaving out those spots, how high should I place this book on my reading list?

      For the curious, my next books are from Pat Kua and Gojko’s new book

  3. Arno Delhij   •  

    Hi Jeffrey, I think this is a nice and catchy description. But could we do retrospectives any other way than this. Personally I don’t think so. Any other way of working with no specified objectives measurable and assigned to people is nothing but a Scrum-but artifarct. Always make sure that you have:
    a) the most valuable problem/challenge tackled first (prioritise your challenges)
    b) be sure not to dive into solutions before you have investigated underlying causes (all to easy to do and I see it very often)
    c) indentify the tasks which go with the “sprint improvement story”
    d) make sure that they fit in the sprint, have clear acceptance criteria and are assigned (ideally the team will pick the tasks up themselves, sometimes with improvement tasks they need a little push)
    e) monitor progress during the sprint and have the improvement on top of your sprint backlog
    f) close the feedback loop the next retrospective on how the team has proceeded. If all done great – if not…..you’ve just earned a new starting point for your retrospective 😉

    • Jeffrey   •     Author


      I love your list. It’s not only complete, but concisely said.

      This is much more structured than I usually see and I like the focus this puts on action items.

      As I think about putting this into practice, I worry about action items taking longer than an iteration, even if tasks can be completed in a shorter time frame.

      I think you would want to manage this so teams do not unintentionally push the team towards “easier” action items instead of those removing the biggest problems and adding the most value, even when it takes longer than a sprint.

Comments are closed.