Why Project Retrospectives Are Challenging

Project retrospectives are challenging. I spoke a bit about this in lessons learned vs. project retrospectives. You might look at a merger, acquisition, implementation of a new ERP system, or even a major upgrade of an ERP or CRM system. These are non-reoccurring events. A retrospective of this type is quite different from a typical agile retrospective, primarily because on this type of project, people will change and the project will not repeat (the definition of a project is that it is a unique endeavor).

At issue here is the fact that if the people will not be the same and the project does not reoccur – then they can’t come up with actions they will apply right away based on what they learned. Ideas for change often just end up in a spreadsheet, a book shelf, or some electronic tool. A big book of “lessons learned” that sits on the shelf gathering dust does not provide much, if any, value.

All that said, there may still be some value. You have to consider a number of key elements when deciding if you want to set up a project retrospective.

Remember that:

  • the people may not be working together going forward — at least in the exact same way
  • the project will not repeat
  • all of the people originally involved may not be available

Determine if:

  • enough time can be dedicated to the project retrospective, given the duration of the project — a one year project will take more than a few hours to have a “good” retrospective and avoid recency bias
  • the retrospective can include breakouts and ways people can say what needs to be said — often in these sessions there are more people than one facilitator can facilitate
  • activities can be planned in a way that deals with people from different parts and “levels” within the organization as well as the fact that many people may not know each other (well)
  • the right mix of people can be included in the project retrospective — can the people who actually know about the project attend?
  • there are incremental team retrospectives that can be used to help people look back and reflect on what was happening many months earlier?

Based on this list, consider your goal. What do you hope to accomplish with the project retrospective?

If you just want to check a box so that you can close out the project, just schedule a small one, invite a few people, then file your report — it won’t matter anyway.

If you actually care about improvement it will be important to find out what items within the project will reoccur. This is one area you can focus on. I need to point out that many of the elements listed above illustrate why ongoing retrospectives that allow teams to improve as they go are so important! Having ongoing retrospectives that you can learn and improve on BEFORE things are over is always better than waiting until the end!

Consider this situation

Giant Mart is acquiring Mini Mart. Giant Mart has an IT team that will merge Mini Mart’s inventory data into Giant Mart’s inventory system. Giant Mart just finished a different acquisition and the IT team is having a retrospective on that event. What can Giant Mart learn? What can they take action on? What are the challenges in applying a retrospective from one event (project) to a different event?

Giant Mart needs to focus the retrospective on what they know will be the same. They should be focused more on the communication and collaboration process in general and less on the specifics of what they would have improved with relation to the data in the last acquisition. Perhaps in the first acquisition, they ran into a problem because the inventory data they attempted to import on the weekend of the conversion didn’t have a ‘purchased date.’ They were in real trouble with the conversion and developed a formula

Project retrospectives that attempt to focus on every project detail are frustrating! And arguably are not really retros. Focus on ideas that help you improve moving forward.

based on the ‘enter date’, ‘ordered date’, and ‘product type.’ If they decide in the retrospective that they should always use that formula, they may be making a huge mistake, since this may not work well for the next acquisition.

Instead, they should be looking to the root cause(s). What are the real issues here? What is changing? What don’t they know?

Some questions they might start with: why did we wait until the cut over weekend to run a full data import? When we ran tests, why were they not automated and why was the company being acquired not involved? How can they get the acquired company involved earlier? [This is “always” allowed, right! :)]

I would be asking: “can we bring some of the people from the latest acquisition to the retrospective from the last acquisition?”  There are many more questions here, but this begins to show why project retrospectives are challenging. The people change and the project is not the same!

Decide What You Want

Decide what you want from the project retrospective. Identify your goal. I know someone reading this just started a project or will be doing so soon — if that is you, figure out how to start doing team retrospectives now. Learn and improve as you move through the project!

If you focus on what is the same from project to project, you can be more successful than if you are targeting individual project specific items. And, of course, realize that what you think will be the same may not be! That is where impartial facilitation helps! If you have questions about facilitation or how to deal with some of the challenges noted here, add a comment below or send me an email.


Subscribe to receive emails with my new posts and Agile Safari cartoons and Follow me on Twitter to stay in touch!

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Great stuff, Jake! One thing I’m aware of as I contemplate this post —  you can use the project retrospective to take a look at bigger systemic issues that were hard to find from the perspective of the team by inviting more people in, especially stakeholders. Even better: if multiple teams worked on the project, it’s a great time to bring them all together and talk about what they would “import” into their next project.

    • Stephen, thanks for your comment! I agree! I spoke a bit about that in Focusing Agile Retrospectives, but as you point out there are many options to import ideas into the next project. We can use retrospectives to start a project as well — actually looking back and then using those to help design the alliance with the team(s). I think the multiple team idea is great! Thanks again!

Jake Calabrese

Jake Calabrese is a coach, trainer, and coach-consultant working to help organizations meet the promise of agile by going beyond agile practices to address culture challenges and help teams and leaders reach and maintain high performance. He has unique expertise as an Organization & Relationship Systems Certified Coach (ORSCC), a Certified Scrum Trainer (CST), Certified Enterprise Coach (CEC), and Professional Certified Coach (PCC), and as a trainer and coach for Agile Companies (helping non-software organizations use agile). Jake created the AgileSafari cartoon series to introduce humor into the more challenging issues we have to tackle. Jake uses ideas from various areas of thinking such as: Lean, professional coaching, neuroscience, psychology, facilitation, brain-based training, improvisation, agile, kanban, and scrum. Jake regularly speaks at local and national conferences including Mile High Agile, Scrum Gathering, and Agile Alliance Agile20xx conferences.

Connect

jake.calabrese@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author