How to improve every aspect of your team

“Mommy, can we have our retrospective and cocoa now?”

As a Technical Leadership consultant, trainer and coach, I get a lot of questions.

About 67.2% of them go like this:

“My team hates/is awful at <PRACTICE/MEETING/THING>, but everyone on the internet says it’s great. What are we doing wrong?”

Of course, as the consultant, they hope I have some wisdom to dispense.

The answer I give is often not what folks expect.

Today, my dear droogs, I’m going to give you free advice that will solve 67.2% of your problems. Not bad for a random medium article.

Without further ado let me present…


I boldly assert that every meeting, practice, relationship and task your team has would benefit from a focused retrospective and experiments.

Hearing grumbling that stand-ups suck? Make the next stand-up a retro about how you do stand-ups.

Programmers dreading your 1:1 meeting? Make the next meeting a retro about 1:1s.

Programmers grumble that your stories don’t have enough detail?

Your boss complain about poor software quality?

Do folks hate your annual evaluations? Users wish you were more responsive?

Spouse wish you listened better? Kids complain you’re always late?

(Sorry, those last two slipped in from my personal life!)

In each case, a retrospective discussion can give the boost leading toward radical improvement and change.

After all, that’s the whole point. To have a meta-conversation about what we’re doing.

Back to the basics

The Agile Manifesto, our holy writ, states:

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

Shockingly, this works not only for building software but for most everything in life.

I’m sure you know how to retro. Sad/mad/glad and other formats work well.

The goal is to get folks talking about what they normally aren’t discussing, understand each other better, and create some timeboxed experiments.

Experiments, not actions.

Experiments indicate an unknown outcome, which will provide learning.

Actions indicate a carved-in-stone approach which everyone has 100% confidence in.

Which is a terrible burden to put on yourself (and your team.)

Instead at the end of the retro, frame the ideas as “experiments we will run for the next X days, and then we will have another retro.”

Notice what I snuck in and the end of that? Another retrospective, where everyone will bring what they learned, and decide on next steps!

Keep repeating the cycle until you are perfect. Which is, of course, never. :)

Looking back at the list above, is there anything that a retrospective discussion couldn’t make better? I think not.