Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, and even celebrity chef-led humanitarian efforts. Yet, has Agile started to lose favor? This prompted us to get back to basics and start a series focusing on the 12 Principles of Agile.

The twelfth and final principle of the Agile Manifesto reads:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These reflective meetings are often referred to as retrospectives. A retrospective’s sole goal is to do as the twelfth principal states and find ways to learn and improve. Talking to co-workers about how to improve can be difficult to navigate. But they can also be exciting opportunities to grow together as a team.

Which Commandment is the Greatest?

All 12 agile principles are valuable guidance in how to build software. But only a few of the principles can be measured: the third, the fourth and maybe the sixth. The rest look more like maxims or values.

So with a list of hard to quantify shoulds and musts, how are we to know whether the team is doing the right thing? The twelfth principle tells us to talk about it!

If you adopt only one #agile practice, let it be retrospectives. Everything else will follow. http://t.co/531yjyK2y5 #mobProgramming

— Woody Zuill (@WoodyZuill) May 20, 2014

Zuill’s logic makes sense. Teams spending time discussing ways to improve affords natural opportunities for review of the other principles. Ideals like “continuous delivery” get put under the microscope of the current project.

When it comes to software product teams build it to be valuable. Simplicity in design is essential. Product teams architect it so that it can accommodate changing requirements.

If Conway’s Law is true, then the team must mirror the guiding principles used to build the software. If they come from the team, then the software will be imbued with them.

If the software must welcome changing requirements late in the process, then so too must the team.

• For the team with dissatisfied customers, what’s the clearest path to providing value?
• For the team adrift without a business SME or product owner, how can they get one assigned?
• For a team that survived a death march, how do they avoid that situation again?

A team should be subject to the same sorts of iterations and improvements that the software itself receives from its team.

At Simple Thread we have a saying that “great software is about great people.” Being great is an incremental and iterative process and both the software and the team can always improve.

Not Another Teamwide Meeting!

Most teams do not lack for meetings, so why add another? Some teams compromise by folding retrospectives into another meeting like a standup. Mixing up-close tactical discussions with strategic critical analysis can create problems. For team members it can become a “can’t see the forest for the trees” situation. Or rather “are we discussing the forest or the trees?”

Seeing the forest requires unencumbered time to reflect. This should then allow space for a more thoughtful and reflective experience for all.

The value of another’s experience is to give us hope, not to tell us how or whether to proceed.

Peter Block

It is unlikely that only one person observed something happening on a team. But giving voice to it can confirm and crystallize nagging feelings.

Able to put aside the next pull request, conversations should be more strategic in nature. These proud accomplishments, existential worries, gut instincts, or epiphanies can yield long-term gains.

Retrospection for Proaction

There’s no hard rules about what retrospectives must or must not be. But experience has led to the following set of best practices.

How Regular is Regular?

There is a clear Goldilocks Zone for how often retrospectives should occur. Too often? They lack insight and feel burdensome. Too infrequent? Timely insight gets forgotten and personal tensions might build.

It depends on your team and the scope of your work. It is best for the group to seek consensus before agreeing to a cadence.

Retrospectives should match the rhythm of the work they’re evaluating. The questions to ask yourself are, “How fast are we learning? How fast do we want to learn?”

Aaron Dignan, Brave New Work

Did we find a meaningful way to adjust our process between now and the next retrospective?

Mirror the existing work patterns. Does the end of a sprint or epic feel like the right place to reflect, listen, and adjust? Use that as a starting point.

Is the current interval too frequent? Then scale it back.

Keep making the same mistakes sprint after sprint? Ratchet up the retros!

Answer Me, These Questions Three

Leading questions suck.

Open-ended questions allow for all sorts of meandering discoveries and insight. Typically, a retrospective asks three open ended questions that follow the Rose, Thorn, Bud model of reflection.

1. What went well?
2. What went poorly?
3. What can we improve?

These questions can lead to valuable insights. They all point towards improvement but it is hard to be more open ended than that.

But how can we get there if no one is brave enough to honestly answer the questions?

We’re In the Trust Tree

We have another problem.

These questions set teams up for some vulnerable and wounding conversations. If a team does not yet trust each other, what’s the cost of answering these vulnerable questions?

Is this a place to feel heard and not judged? Will they think I’m not a team player by complaining? What if I hurt someone’s feelings? What if someone hurts my feelings? Will saying this come back to bite me? 

Amazing teams building amazing things must come from a place of psychological safety. Psychological safety asks “can we take risks together for the common good as a team and not feel insecure or embarrassed?”

The earliest work on the subject was done back in the 1960s. Recently Google deepened the research on the subject and codified the results on their re:Work website.

Gallup researched the subject and discovered the following:

[…] just three in 10 U.S. workers strongly agree that at work, their opinions seem to count. However, by moving that ratio to six in 10 employees, organizations could realize a 27% reduction in turnover, a 40% reduction in safety incidents and a 12% increase in productivity.

It is clear that there’s gold in the hills of psychological safety, but how do we get there?

Lead By Example – Servant leadership is one of the most powerful tools in building team dynamics. If a leader wants a team to be vulnerable, they ought be vulnerable first. It is my firm belief that people are drawn to that behavior when they see it modeled before them.

Listen, Then Adjust – If teams share insights or concerns and then they are not acted upon, what happens then? Like the tree falling in the forest, the team’s trust won’t improve and neither will the team’s results. If a lineworker at Toyota were to pull the andon cord and no alert sounded, what’s the point in pulling the cord? So it is when people share worries or areas of improvement that could be acted upon.

Successive Iterations – Rome, and trust, was not built in a day. If team members see their concerns addressed then they are more likely to respect and take part in the process over time.

Enter the Prime Directive

While inspiring, leading by example can contain inconsistencies.
So upholding an external framework that everyone can buy into is helpful.

To foster psychological safety on teams, Norm Kerth coined a term he called the Retrospective Prime Directive. The Prime Directive frames the desired changes with gratitude for the work to-date.

It states:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Norm Kerth, Project Retrospectives: A Handbook for Team Review

Too often I’ve joined teams filled with shame, guilt, and defensiveness about the state of the product.

In my experience, if genuinely intended, stating the Prime Directive is a great olive branch. It can signal that the goal is understand and make improvements. Not to complain about the current state.

Becoming More Effective

Agile became a way to express the culture forming around how to best make digital product teams more effective.

This comes through assessing. Where are? How did we get here? How we can make incremental improvements over time? This sets us up to the do the most important thing: deliver valuable software to customers.

Upholding, let alone remembering, all the twelve principles is challenging. But a committed and trusting team who can hold each other accountable is a great start. The product and its team will increase its value one retrospective at a time.

> Table of Contents for the 12 Principles of Agile