Our blog articles are translated to English by machine and may not always be accurate - sorry for that.

If you understand German, we recommend to switch to the German version.

Screenshot 2019-07-16 at 19.15.18

Scrum retrospective method: 200% more successful through psychology

Share on linkedin
Share on twitter
Share on facebook
Share on email

Lieutenant John Kelly concentrated. He was the leader of a team of 5 lieutenants in the US Navy who had only one task: to determine as quickly as possible whether surrounding warships were more peaceful or hostile to them. Time was running. 

But Lt. Kelly was relaxed because he had learned something in a two-hour training session beforehand. A Scrum retrospective method that led his group to achieve an excellent result. 

Don't worry: what he learned can be used not only in the military, but also in your team. Because it became specific for teams in our VUCA World developed.

Do you want to use the latest psychological research in your retrospectives? Then take a look at our retrospective tool (can also be used remotely):

A Scrum retrospective method from science

The task described Lt. Kellys was the final part of a team method training in overseas warfare. It prepared the participants for their assignment as head of a NAVY ship.

13 teams participated in the team training. These were again part of a scientific experiment (Smith-Jentsch, Cannon-Bowers, Tannenbaum & Salas, 2008). Before the task, they were randomly divided into an experimental group (7 teams) and a control group (6 teams). 

The control group was prepared for the task in the classic way. And the test group received a slightly modified training (1).

This slightly modified training resulted in the test group acting like professionals among beginners compared to the control group. So show the performance results at one Scale from 1 (bad) to 5 (good)

What kind of training leads to such a difference?

0
Average performance in the control group
0
Average value of the performance in the test group

The power of a good Scrum retrospective

There was one variable, one difference in the method being trained. This distinguished the experimental group from the control group. To understand this difference, let's take a look at the entire training.

In preparation for the above task, both groups performed two exercises. Following these exercises, both groups reflected on it. 

Specifically, about what went well and what went bad during these exercises. To improve their teamwork (Smith-Jentsch, Cannon-Bowers, Tannenbaum & Salas, 2008).

This subsequent reflection also has other names in science: “Team debrief”, “After Action Review” or “Team guided self-correction” (Salas, Nichols & Driskell, 2007)… 

… Or synonymously in the practice of agile work “retrospective” (the conclusion of the sprint according to Scrum).

Both the control and the experimental group therefore carried out a retrospective. However, these retrospectives were conducted very differently in the two groups. 

The control group practically carried out a classic retrospective. However, the experimental group did a retrospective with a slightly different method. Let's call this type of method nitro-retro.

That brings us to the difference between the two groups. The key variable, the secret ingredient, the magic word within the nitro retro is called the team's “shared mental model”. 

That's exactly what you have to do as an agile coach, Scrum master and Product Owner work. Respectively. that is what makes good agile coaching and agile team development. And it doesn't matter if you look for Lean startup or in Safe framework is working.

When Scrum Retrospectives Work - The Secret Method

What is a mental model? The theory behind it, based on knowledge from cognitive science, social psychology and anthropology: people perceive reality, external stimuli, through internal, cognitive “mental models” (also “frames” or schemes); Lee, Johnson, Lee, O'Connor & Khalil, 2004).

We have a mental model for everything. From “how do you behave in a Chinese restaurant” to “what makes good project management” to “how do you make toast”. 

Tom Wujec, for example, is the author of 4 bestsellers about creative thinking and design tools. He often starts training with an explanation of what mental models are. 

To do this, he asked the participants to do the following: Draw how toast is made. This creates drawings like the following. Three people with completely different mental models (for source):

Mental model 1
Mental model 2
Mental model 3

This is how people's mental examples of how to toast look like. Further examples and the Ted Talk can be found at www.drawtoast.com

Why is Tom Wujec doing this? What are mental models good for, or what does this have to do with successful retros and good teamwork?

First: Everyone also has a mental model for successful teamwork. Few people, let alone teams, are aware that they work according to a mental model for “team processes”. Even fewer people are aware that this mental model significantly controls our communication and behavior.

Secondly, and here's another crucial tip: teamwork works better, 

  • the more precisely a mental model hits reality and 

And exactly this knowledge can be used for successful, good retrospectives at the end of the last sprint. Let's get back to Lieutenant Kelly.

An exemplary mental model

Lieutenant Kelly had received training. This has given him the importance of mental models. He was also introduced to a mental model for successful teamwork in a military context. 

This model was supplemented by tips for its implementation - in the form of behavior anchors.2

It conveyed the “right” mental teamwork model. For the tasks that the teams performed during the training. 

And finally, Lieutenant Kelly was instructed and trained in it. In using this model as a basis for reflection for his team retrospectives.

The model consists of four dimensions with 11 behavioral anchors. It looks like this (see footnote for more info3):

  • information exchange
    • Find information from all available sources
    • Share information with the appropriate team members
    • Big Picture & #8216; Deploy updates
  • communication
    • use the correct terminology
    • Provide complete internal and external reports
    • Minimize unnecessary communication
    • clear and clearly audible communication
  • Supportive behavior (backup)
    • Correct mistakes of other team members
    • Support is actively requested and provided if necessary
  • Team initiative / leadership
    • Provide guidance and suggestions for mutual improvement
    • Identify clear priorities at team and individual levels

In the control group, the “classic” agile retrospectives took place like at the end of a scrum sprint. As a sequence, the events that took place during the exercise were discussed chronologically.4 

The general question was: what went well? And what could go better next time? 

Accordingly, tasks and topics were discussed in the order in which they appeared in the exercises. But continuous improvement is even better.

The basis for the magical Scrum retrospective method

The retrospectives of Lieutenant Kelly (quasi the group's Scrum Master) and the rest of the experimental group, on the other hand, had no chronological sequence. 

They were moderated or structured using the previously trained model. (Of course, this does not exclude that the classic five phases of a retro were not taken into account).

Here, conducive or less conducive behavior was reflected within the four dimensions. This has the two advantages described above, which hopefully all Scrum Masters will soon know:

  1. First, it didthat the team’s shared mental model of teamwork was aligned. Everyone had a very similar idea of how successful teamwork works. Imagine if a team member had been asked about the team training “Should you rather communicate as much as possible or try to avoid unnecessary communication? And are general big picture updates unnecessary or helpful? ”.
    Every team member would have had the same, unambiguous answer. The answer would probably not have been so clear before training.
  2. Second, this led to itthat everyone on the team wouldn't just give the same answer. But also the right one. The model was previously developed and validated across various studies.
    As a result, the team could be sure that the model reflects the behavior of an elite team relatively accurately (Mathieu, Heffner, Goodwin, Cannon-Bowers & Salas, 2005).


An example from the startup world

Another simple example: Ben Horowitz is the founder of Andreessen Horowitz, one of the most successful venture capitalists in the Silicon Valley. 

He noticed that the product owners in his first company Loudcloud performed very differently (Horowitz & Kenerly, 2014). So he wrote a simple leaflet. And that's what makes an excellent manager.

You could also say that he passed on his mental model for an “excellent manager”. Including the naming of specific behaviors. For example: “An excellent manager knows every competitor”. Or “An excellent manager has a 1: 1 with his team members every week”. 

This led to a significant increase in manager performance (Horowitz & Kenerly, 2014). With a simple tip, one Nudge, or an “alignment” of the mental model.

Equivalent matching of the mental model to the question “what makes good project management” should have similar effects in the corresponding environment. 

Likewise, a Kanban Board (another recommended method) leads to a comparison of the mental model with regard to existing tasks and their priority.

The following graphic (after Rudolph, Simon, Dufresne & Raemer, 2006) illustrates the mechanism of corresponding, good retrospectives again:

 

Mental models are invisible, but derivable. They are in the minds of team members and Scrum Masters. They influence the behavior or “actions” and the measures. The latter influences the results. Which have a retroactive influence on the perspective or the mental models of the team members.

Overall, team members know better about Nitro-Retro, what they can expect from each other and how they have to coordinate. 

An appropriate form of retros minimizes knowledge gaps and misunderstandings. Some conflicts are prevented. 

This is because people are really talking about the same thing. And obviously the cooperation is significantly improved (Smith-Jentsch, Cannon-Bowers, Tannenbaum & Salas, 2008). 

How does this knowledge benefit us in practice? So that it also has a positive impact on your releases or similar. Has?

How to Nitro-Retro - the Scrum Method as a workshop

Well, a little tip: If you do not generally do retrospectives (whether in Scrum Sprint format or by another method), then introduce them. Now. 

Because the results in the above study are no exception. (And don't worry - managers can also moderate retros).

A broad-based meta-study showed that retrospectives lead (or synonymously according to the scientific definition “team debriefs”) teams to 25% better performances. 

Even though teams only invested a very short 18 minutes in them (Tannenbaum & Cerasoli, 2013). 

Good retrospectives help one thing above all: gain insight. 

It is not without reason that "gaining insight" is one of the five phases of a retrospective in the Scrum methodology (or rather in the Scrum Framework).

Make good retrospectives even better

If you are agile coaches, scrum masters and product owners, you probably already live agile methods. And already did a retrospective in the last sprint.

Regardless of this, you can now improve future retrospectives based on the information explained. (In my view, this knowledge should actually be integrated directly into the Scrum Master certification ...) 

For this we have developed a workshop that you and your team can, for example, conduct as part of a retro.

Here are the steps. You should plan 1 to 2.5 hours for them, depending on the size of the team. (Don't forget, the retrospective is still a protected space):

  1. In the spirit of 5 phases of a retro, start with the “Set the stage”. (You can find general inspiration on this and on the further process at, for example Retromat).
  2. Continue with the “Draw Toast” exercise (see Ted Talk): Without extensive instructions, tell your team members that everyone should record for themselves how toast is made from their perspective.
    For this they have 2-3 minutes. Tip: Of course, it doesn't always have to be the toast example. Vary the task if necessary to generate exciting new drawings. 
  3. Let everyone present their drawing once. Discuss the similarities and differences of your “definitions” of the mental model. Did anyone paint people? One hand? Does everyone have a toaster? Did some draw additional products?
  4. Now continue moderating by explaining to the team what mental models are. For example, some immediately think of hands when they think of “making toast”.
    Engineers may think of the technology behind it. If necessary, look at the entire Ted video for this step.
  5. Explain to the team that a shared mental model of work can greatly facilitate teamwork. But it should reflect reality as closely as possible (Mathieu, Heffner, Goodwin, Cannon-Bowers & Salas, 2005).
    Everyone should contribute so that you as a team can develop the most accurate mental model possible. At the moment everyone probably has a different picture.


    To make it easier to understand here, you can do this here graphic demonstrate. It shows how 6 blind Scientists, depending on the perspective, would describe an elephant. Equivalently, everyone on the team has a different perspective on work & #8211; and none is wrong.

  6. In the next step you ask for the following: Everyone records (possibly on typical Kanban cards) his / her mental model of which processes your teamwork consists of. In addition, everyone can also record behaviors or characteristics that make up successful processes from his / her perspective.5
  7. Now the team has time to arrange the cards in a model or a meaningful structure.
    According to the Ted Talk, sometimes this works just as well or even more efficiently if there is no talking.

    Peter M. Senge is probably mainly responsible for the introduction of the term "learning organization". It expresses this important step in one Youtube video on the topic “Systems Thinking” like this:

    “If I am not ready to question my own mental models, then I can forget to discover hidden potential. You have to bring together different people from different angles who see different parts of the system. And seeing something together that none of them can see individually. ”

  8. At some point it becomes apparent that the team is reasonably agreed. Then everyone can sit down again and talk about the experience.
    Because good moderation means involving all team members as often as possible. The following questions can support good moderation that encourages reflection:
    • What part of the mental model was to be expected?
    • Which part of the mental model surprises you?
    • In your view, where is there still room for improvement in the mental model?
    • Which positive behaviors can you possibly add?
    • Which part of the mental model had any of you not thought of before?
    • How did it feel to develop the mental model silently?
    • Does the mental model fit your team goals and values?
    • Which parts of the mental model may dominate your processes? Do they dominate?
    • Which parts of the mental model should be considered more often?
    • Where is there a bottleneck or a particularly critical set screw in this model?
  9. After this reflection, a model should be agreed. And a conclusion should be found according to the five phases of a retro. (For examples of this and the general procedure, see Retromat). In the next step, the developed model can be called up regularly in retrospectives. It can and should serve as the basis for your reflection.
 

So much for a shared mental model of your processes. Maybe you will try the workshop (possibly in a modified form) in the next sprint. 

We look forward to hearing your experiences on the workshop concept. Maybe something different from what you know from the Scrum Guides. We are open to tips on how to improve it!

I hope that the description has given you at least one new idea, maybe even measures for improvement. (In the latter case, don't forget to stick to the agreed measures). 

If only agile team development was as easy as that Robotic process automation would…

Successful teamwork

In addition to this teamwork model, there is of course also a model for what constitutes successful teamwork on a psychological level. 

For one of the relevant factors, see for example ours Blog post on psychological security.

So who is going to make sure that it runs as a team? 

What is a “right” mental model for successful teamwork on a psychological level? Here we have reached the task of the Echometer software or our tool.

Meta-studies suggest that there are psychological variables that are general prerequisites for motivated teams. No matter whether they consist of project managers, specialist lawyers or software developers. 

We help you to integrate these general factors into your mental model for successful teamwork. 

To reflect on the factors and to continuously develop you. In other words, to optimize teamwork with the help of truly successful retrospectives. (Design thinking and Lego serious play we can also recommend it).

Continuous improvement

If you want to improve your teamwork with Echometer retrospectives - in one continuous Improvement would come - contact us with pleasure. 

Otherwise, we would be happy to help you to include “mental models” in every Scrum Master certification. And share this post with your colleagues. # Thank you 🙂 

By the way, don't worry. One thing is not in question: This will not be our last article on retrospective methods! 

Possibly. you want to design your retro using playful methods, for example. Then hit the three methods from this article rather your taste.

Do you want to use the latest psychological research in your retrospectives? Then take a look at our retrospective tool (can also be used remotely):

footnotes

1) For the statisticians: The results of a t-test showed that this difference is statistically significant (t (11) = -6.72, p <.01; one-sided). With a very high effect size of d = 4.1 (!).

2) This model was previously developed across various studies (including Johnston, Smith-Jentsch, & Cannon-Bowers, 1997Smith-Jentsch, Johnston, & Payne, 1998).

3) Various researchers developed a model as part of the TADMUS program - Tactical Decision Making Under Stress. As a valid, reliable model, it should serve as the basis for later research in the military on teamwork. 

Within different studies (for an overview, see Ramachandran, Jensen & Salas, 2008) a model emerged for this. It has been referred to as the Anti-Air Teamwork Observation Measure (ATOM). It was then used as a basis for team training at NAVY and the Marines, for example as part of 9/11.

4) You don't want to give the impression that all retros are chronological. A classic retro refers to a “cliché” retro that observes the 5 phases of a retro and poses the “cliché” questions mentioned.

5) This would also be possible with other questions. So you could also ask how your team creates value from the perspective of each individual team member. 

Or where your team is in the value chain. However, this question would of course be less suitable as a basis for the ongoing retrospectives in the Scrum Sprint that take place afterwards.

References

  • Christian, MS, & Slaughter, JE (2007, August). Work Engagement: A Meta-analytic review and directions for research in an emerging area. In Academy of Management Proceedings (Vol. 2007, No. 1, pp. 1-6). Briarcliff Manor, NY 10510: Academy of Management.
  • Horowitz, B., & Kenerly, K. (2014). The hard thing about hard things: building a business when there are no easy answers. New York, NY: Harper Business.
  • Johnston, JH, Smith -Jentsch, KA, & Cannon & #8211; Bowers, JA (1997). Performance measurement tools for enhancing team decision-making training. In MT Brannick, Salas, E., & Prince, C. (Eds.), Team performance assessment and measurement: Theory, methods, and applications (pp. 311-327). Mahwah, NJ: Erlbaum.
  • Lee, M., Johnson, T., Lee, Y., O & #8217; Connor, D., & Khalil, M. (2004). The Conceptual Framework of Factors Affecting Shared Mental Model. Association for Educational Communications and Technology.
  • Mathieu, JE, Heffner, TS, Goodwin, GF, Cannon ‐ Bowers, JA, & Salas, E. (2005). Scaling the quality of teammates & #8216; mental models: Equifinality and normative comparisons. Journal of Organizational Behavior: The International Journal of Industrial, Occupational and Organizational Psychology and Behavior, 26 (1), 37-56.
  • Ramachandran, S., Jensen, R., & Salas, E. (2008). Developing Team Performance Models: From Abstract to Concrete. Interservice / Industry Training, Simulation, and Education Conference (I / ITSEC) 2008.
  • Rudolph, JW, Simon, R., Dufresne, RL, & Raemer, DB (2006). There & #8217; s no such thing as “nonjudgmental” debriefing: a theory and method for debriefing with good judgment. Simulation in Healthcare, 1 (1), 49-55.
  • Salas, E., Nichols, DR, & Driskell, JE (2007). Testing three team training strategies in intact teams: A meta-analysis. Small Group Research, 38 (4), 471-488.
  • Smith-Jentsch, KA, Cannon-Bowers, JA, Tannenbaum, SI, & Salas, E. (2008). Guided team self-correction: Impacts on team mental models, processes, and effectiveness. Small Group Research, 39 (3), 303-327.
  • Smith-Jentsch, KA, Johnston, JA, & Payne, SC (1998). Measuring team-related expertise in complex environments. In JA Cannon -Bowers, and Salas, E. (Ed.), Making decisions under stress: Implications for individual and team training (pp. 61-87). Washington, DC: American Psychological Association.
  • Tannenbaum, SI, & Cerasoli, CP (2013). Do team and individual debriefs enhance performance? A meta-analysis. Human factors, 55 (1), 231-245.
On a similar note

Articles you may also be interested in

Want to get started?

Test team retros with Echometer for free & drive agile work in your organization.

I recently got an ebook too "12 retrospective methods from psychology" written - interested?

Christian Heidemeyer, Psychologist & Scrum Master