Improving Retrospectives

A friend forwarded this email to me:

I just wanted to share a tip that has made a world of difference for our scrum. I read through this book about 4 months ago



And have implemented some of the practices in it. This has taken our retrospectives from being a 1 hour meeting where we went around the table and said what was good and what wasn’t (and then never really changed anything) to a full 3 hour incredibly productive conversation that the whole team participates in and we actually implement the changes that we propose in! It’s been a complete 180 from a meeting that was a waste of time to something the team looks forward to doing at the end of each sprint.

So if you haven’t read this book, I really recommend you do and try out some of the things in it (even if you think they are a bit cheesy and that the engineers will never tolerate it). It’s a quick read (3 hours tops for the whole book) and will at least give you some ideas for improvement of your retrospectives.

Woohoo! This is the highest praise an author can receive. (I don't think the activities are cheesy!)

And, for your reading pleasure, two recent articles on retrospectives:

Making Retrospective Changes Stick

Eight Reasons Retrospectives Fail (And What You Can Do About Them)

Context matters for team trust

I still hear about managers taking teams on ropes courses and splat ball courses for "trust building."

It doesn't work. Trust always exists within a context and relates to a specific sphere of action and expertise.

So if you want to build trust on a ropes course team, a ropes course makes sense. If you want to build trust on a splat ball team, a splat ball course makes sense.

But neither makes sense for building trust on a software team because it is not congruent with the context.

That takes forging agreements on how people will work together and then following them. It takes fostering a culture where people can ask for help without sanction and take sensible risks without sanction.

A team outing may help build trust if it helps people get to know each other--humans tend to trust people they know and cut people a little more slack when they known them and feel some connection. But trusting that someone won't let you fall off a 15 foot platform isn't the same as trusting that someone has good technical chops and will follow through on commitments.

Yo-yo managers break trust

Most of the time I hear people talking about trust, they are talking about trust between team members. It's equally important to have trust between managers and team members. In fact, the relationship between an employee and his/her manager consistently shows up as a key factor in retention.

One of the ways that managers in the middle of agile transitions break trust is by giving a decision to the team and then taking it away, as in Tale of a Yo-Yo Manager.

What trust means for teams

It’s a truism that trust is the foundation of teamwork.

But trust is a big word. What do we really mean when we talk about trust?

First, trust exists within a context. The sort of trust that you need for a productive working relationship is different from the trust you need for a healthy marriage. And it’s certainly different from the trust you need on a ropes course (which is why that sort of team building activity seldom has much effect).

What you need for productive working relationships is trust that says:

I believe you are competent to do the work

I believe that if you have an issue with me, you’ll bring it up directly

with me, not talk behind my back.

I believe will follow through on commitments—or let me know when you need

to renegotiate.

I believe you have good intentions towards me and the team.

And there’s a prerequisite for trust: a person needs to have a capacity for trust.

I lost interest...

...in blogging for a while and took a break.


Anders Vesterberg read Behind Closed Doors and has some nice things to say on his blog.

Simple principles

Rothman’s and Derby’s main tenet is that the principles of good management are not that difficult to understand. They discuss for example one-on-ones, portfolio management, feedback, coaching and delegation. The thing is to consistently and reliably perform these practises week after week.

Not that difficult, but not always easy. Systems drive behavior, and it's not always easy to recognize and counter act the affects when you're in the thick of it.


I'll meet Anders in person in January at PSL in Sweden. His review was an awfully nice electronic introduction :-).