Let’s look at a few distinctions between the two process improvement practices that make all the difference in their usefulness for making projects and job situations better! An extreme way to look at the goals of these practices is: what makes your work easier (retrospective) versus what did someone else decide is best practice (post-mortem)?
First, look elsewhere for a “how-to.” There are many published materials on how to do a sprint retrospective and a post-mortem. We are looking at the differences in the mindset. To look at how post-mortems and retrospectives are different, let’s go back to the approach and foundation for these meetings. The following distinctions between the Agile and traditional software development mindset loom large in the mindset entering retrospectives and post-mortems.
1. Chickens and Pigs vs. Top Down Management
The chickens and pigs story illustrates that in Agile, the working team (pigs), not management (chickens) dictates what the team does. Only the people who have skin-in-the-game decide what to do. Ideally, what this team wants to do and how it wants to do it falls on the team. In post-mortem, a “Top 10” style problem list is drawn up that later needs to be approved by other people─not the team members or those doing the work, then scheduled (or not) by other people, and budgeted by non-team members, who will decide for the team if they like the idea. This is always a tough part of the process─“selling” change to management, even though management will never work under the conditions you are suggesting to fix.
2. Lean Manufacturing Principles
In most agile practices, there are few to no “process” documents. What documentation that does exist will be lean or light. In sprint retrospectives there is little documentation to deviate from or reference against. Post-mortem meetings can usually point to documents, approvals and sign-offs that are service level agreements (SLAs) teams agree to. If these agreements are not met, delayed, incur problems, then the documents will help “make your case.”
Lean principles make change more agile, dynamic, but have drawbacks of few reference points and often leave big gaps of “no one realized was missing.” With no big process document revisions and approvals, the improvement process is very different in Agile. For better or worse- both these situations have drawbacks.
3. Fail Fast
Most teams that are Agile understand the first two points. The third point is often deeper in discussions of Agile─try something. If it works, use it! If it doesn’t work, find out fast and get rid of it! Try something else. This notion of change in process and consistently improving practices and customer satisfaction over process, generates a more cooperative, thoughtful, dynamic approach in how-to-get-things-done than any traditional post-mortem can. By definition, agile is dynamic, flexible, and evolving.
4. People and Interactions Over Process and Tools [Agile Manifesto First Value]
Just that! People and our interaction with one another, how we get along and reducing job stress level is more important then what any process document says or what some tool dictates as to how you must track, trace and do anything! That is Agile. It is completely non-traditional in this sense. It’s about people, not process. In post-mortem, the tool and process win. In retrospective─ how we get along wins every time!
5. Role of Project Manager vs. Scrum Master
The Scrum Master: the great destroyer of obstacles. The project manager: gets it done. The key distinction between a Scrum Master and a project manager is universally agreed that this scrum master is the destroyer of obstacles. Their primary job is to remove obstacles, to make things easier, get more information, get better estimates, and support the team. A project manager has a very different goal─get the product as close to schedule and on budget.
If there are tasks that become obstacles, epics instead of user stories, user stories that have bad estimates, insufficient interaction with a customer or business analyst, the scrum master is charged with fixing the problem. If they are not observing these problems themselves or upon hearing it from the team not fixing these problems the scrum master then becomes the problem. Their only job is removing the obstacles. Think about how this impacts the attitude toward change in a retrospective.
6. Timing
Fix a problem when you see it, not six months later!
Worst case: In traditional projects (not limited to waterfall but waterfall style projects) if you spend nine months working on a big project, a week later at a conference table with 20 people you’ve been arguing with for the last nine months only to continue the frustration in the next project─ it’s understandable why people are fatigued and angry!
When you have a sprint retrospective, the short release/project just ended. You can point out a problem in the user story that came into the backlog three weeks ago and not nine months later.
Retrospective: immediately fixes and moves on
Post-mortem: drawn-out and too late to change anything
7. Amount of Measurement
In Agile, measurement is not as consuming as can be in traditional projects. By the book, in Agile you measure burn-down and velocity. That’s it. Many teams take some bug measurements, but not the giant dashboards common in traditional projects.
Traditional projects have more measurement opportunity than Agile projects. Excessive measuring is a time drain and measurement does not always point directly to problems. But efficient measurement can give you a lot of backbone or even evidence for improvement discussions. This is a big bonus in traditional project post-mortems. You may be able to point to evidence to fix problems─this is not the case in Agile. You may only have opinion and feelings.
None of this means that post-mortems are doomed to fail─post-mortems can work! I have many experiences of them being the catalyst for great and successful change. But they are more tectonic. They are best/most successful when there is mindset change or paradigm shift. It is tough to have post-mortems work when it means writing or updating a process document, rounds of editing of the process docs and approval and sign-off meetings.
We can continue to do traditional style post-mortems but have them be more effective with a new mindset. You can have an Agile post-mortem! We don’t have to call it chickens and pigs, but we can have a more democratic rather than authoritarian process. People can agree to try something and see if it works. Prepare for the post-mortems by highlighting better open communication, searching points of agreement, and remove personal barriers. It will have a giant effect.
We shouldn’t get the impression that the grass is always greener on the other side and every Agile retrospective is a resounding success! There are some problems creeping up with companies that have been doing Agile for a while, especially those who have many Agile teams.
As a result of individual self-directing teams doing what makes their work most efficient, they will very often have different practices, different definitions of done, differing amounts of unit testing or automated regression tests, tool use, “light, less is more, evolving design” etc. By nature, some teams will say this suggested practice does not work for our team, and changed it. This very often leads to integration problems.
Does this sound like a commercial to become more agile or implement some more agile processes as process improvement? I hope so…
I wasn’t ttaloly happy with Reality, so maybe People is the better 2nd input, which also addresses Bob’s comment.I’d also consider replacing Team with Capability to make it more general.