Debriefs

I’m working on a new assignment as part of an agile coaching team leading a transformation at a large organization. One of my fellow coaches is also a former Navy officer. We’ve had a number of conversations about how many of the techniques developed by the military can be applied to make any team a high-performing one.

One particular tool is debriefing. I’ll admit, I didn’t do a lot of this in my military career, but the idea is to take time after any activity to review how it went. Kind of sounds like a retrospective, doesn’t it?

As an agile coach, I find this is a great tool. Just the other day I observed one of my teams run a stand-up. As soon as they were done, I gave them a debrief. It only lasted a minute. I highlighted what they did well and where they could improve. I have used the same approach with other teams on everything from iteration planning to retrospectives...sounds kind of “meta” but why shouldn’t you evaluate how effective your retrospective was? This technique is based on the approach of learning a new idea, practicing it, and getting feedback to reinforce the idea.

Learn, Practice, Reinforce

One key to debriefs, and I think this is important for a good retrospective, is to start by stating the goal of the activity. At the end of the iteration, can your team members state what the iteration goal was? How else can you evaluate how you did without thinking about what you set out to do. 

Retrospectives

I mentioned in my last post that I'm on the blog team for the PMI Netherlands Summit, taking place June 13th in Zeist - The Netherlands. One of the sessions is on retrospectives; it's titled Retrospectives: your lessons learned on steroids to help your team / project in your continuous improvement. 

A key tenant of agile projects is to inspect and adapt and that is the purpose of retrospectives. We use these as opportunities to help us identify ways to improve. We should be conducting retrospectives on a regular basis, normally at the end of each iteration.

This past weekend I was at the PMI Leadership Meeting for the communities. After the official program ended, the Agile Community got together and had a retrospective of our work since our last time getting together. The idea of retrospectives can be applied to operations as well as projects. The idea is the same, pick a time, take a step back, and think about how you can work together better. We came up with some actions to help us better deliver value to our customers going forward. You should try it, and if you don't know how, maybe you should think about attending the conference.

The Zeigarnik Effect

An interesting discussion came up on one of the agile groups I subscribe to; the Zeigarnik effect. What this theory says is that people remember unfinished tasks better than they remember finished tasks.

The context of the discussion was retrospectives. During a retrospective, people will be less likely to remember the tasks that completed smoothly in the project, things that fall under the category of what did we do well. Since these are important, you want to make sure people remember them.

One of the tools I use in retrospectives come from Norman Kerth's book. The tool is building a timeline of the project and having people identify key events throughout the project. This is one way to help people remember. Another technique is to hold your retrospectives often; at the end of the iteration rather than waiting until the end of the project.

As I was thinking about the Zeigarnik effect for this post, I also realized it impacts your work in progress (WIP) limits for Kanban. The more things you have in progress, the more things that you are trying to remember. Get your WIP to high, you start forgetting what you're supposed to be working on. So how much unfinished work are you trying to deal with?

On a side note, if you teach, you can use this effect to your advantage. Give your students an assignment right at the end of the day. They will keep thinking about it until they have time to finish it. They'll learn their lesson better than if they finished the assignment in class.

Making Lessons Learned Work

I had a project go live this week, always a good thing. I mentioned that we ran our retrospective last week. Today I came full circle with that discussion. I pulled together the other PMs in the company for an internal discussion of the results of the retrospective.

We did find one common theme that extended to other projects we've executed. And while we discussed how to address the issue, that isn't the point here (but maybe for a future blog post). Today I wanted to discuss knowledge management.

Knowledge management is about changing behavior. If I conduct a lessons learned session and in the future review those notes as I'm preparing for a future project, that's a step in the right direction. It beats putting the notes in a shared drive and never looking at them again. If I pull together my community to discuss the outcomes, that's even better.

So what have you learned lately and who have you shared it with? Do you have an internal team to share with? Would it be a good blog post? Maybe an article for a magazine. Don't just keep it to yourself.

Today's Lesson Learned

I am wrapping up a project this week, and yesterday I brought the team together for our retrospective. One topic that came up was also brought up at my presentation at the PMI EMEA Congress in Amsterdam last week. The topic was how agile teams fit into a non-agile environment.

On this project, I brought my team in with me, agile and ready to go. My client said they were starting to use agile, but it wasn't widely adapted yet. The problem we had was at the intersection between our team and non-agile teams that were doing some of the development work for our project.

Since these other tasks were not complicated, I didn't take into account how long they could take. I also didn't account for the fact that these other resources were not dedicated to my project and had conflicting priorities. You can probably guess the results, we were held up waiting for delivery from these other teams.

So what do you do in this situation? In the future, I will be more actively engaged with these teams and not depend other group's managers to oversee delivery of their components. I'll make sure timelines are understood and deadlines are set. I know I need to engage these other groups sooner in the project and understand what their delivery approach is so I can follow any procedure I need to in order to meet my schedule. In addition, I'll think about contingencies in case there are delays with other groups.

Agile & non-agile can work together, but don't forget that everyone may not be moving at the same speed or the focus your team has on the project may not be the same as other groups that are supporting multiple projects.

Retrospectives

Last week was the end of the first iteration on one of my projects. We had a review with the customer and then the project team held our retrospective. We really focused on 2 things; what did we do well that we want to continue doing and where can we improve for iteration 2.

I first learned about the concept of retrospectives after reading Norman Kerth's book Project Retrospectives: A Handbook for Team Reviews. You can also find more on his site, retrospectives.com.

To often I've been in organizations that pay tribute to the idea of "lessons learned" by holding a meeting after the project, writing some ideas down, and then forgetting about them when the next project starts. I've helped large, global organizations set up lessons learned databases so they can collect these lessons learned from project managers around the globe. None of this is any good without a key ingredient; changing people's behavior. Without that it's just a lesson documented.

I think agile principles really show the value of retrospectives. The retrospective isn't held after the project, it's held often, throughout the project so behavior can be changed immediately. After our meeting last week, we assigned a couple action items and we changed some of our patterns this week. Nothing major, just kaizen at its finest. In 3 weeks, at the end of the next iteration, we'll do it again.