This week we are covering a topic near and dear to a lot of people in the Scrum Community.

Retrospectives.

I have been wanting to write about this topic since day one of this site; however, it kept sliding down my product backlog.

Why?

Mostly out of respect for this topic and the people in the Scrum Community who add to this valuable technique. Namely Esther Derby, Diana Larsen, and Norm Kerth.

This is going to be at least a two part series — maybe three.

Today’s posting looks back at the “old” way a traditional post-mortem was completed.

Think back. Or look at how you may possible be doing them today.

At the end of a project, management may have declared a project “successful.” This can take many formats, including actually delivering working software; however, many times in my own past I have attended these for one reason and one reason only — to complete a “check mark” on some project manager tick sheet. For compliance reasons.

We quickly talk about “lessons learned.” And of course they get filed away into the project notebook (or whatever you use for compliance and auditing).

NEVER to be looked at again.

Gulp.

And.

The team knows the project was a complete disaster.

Management is flying high because a date was “met”.

In the background, they are slapping high-fives with their peers because their project burned through two marriages and one person left the company because they were totally pissed off.

I have seen this happen.

And.

It makes me sad.

In the meeting, everyone gets around to sing happy camper songs and congratulatory awards are handed out.

“Congratulations. Katie worked 100 hour work weeks until the end and pulled in through for the team. And Joe, well, without him, the project would not have been where it is today.”

And them some $25.00 gift cards are handed out.

“Good job,” says the manager.

And.

The team is totally demoralized.

They know the product they delivered was not up to their own personal standards.

They know the product shipped with many bugs (but, because compliance says a product cannot ship with “severity one” bugs, mysteriously the night before all those pesky things were “downgraded” to a two or three — “Wahoo,” say the managers, “We shipped without any high severity bugs!”

Gulp.

So.

It may not be that bad where you work.

Unfortunately, I have seen this — sometimes many times.

And then people leave that project team to start a new project all over again. And guess what? They do the same thing again.

People become numb to the process.

People stop learning.

And.

It happens with both traditional waterfall teams and Scrum teams.

Today.

Is it happening with your team?

In the next part of this series, I am going to give you some solid techniques for dealing with this part of the process.

And not just “deal” with it.

But.

Make is a positive experience for everyone.

And.

Help improve your team and its interactions.

Sound like a dream?

At least it will not be a scary one.

There are things out there to help you.

Really!