Same or Different? Retrospectives and Post-Mortems

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…

Michael Hackett

Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006).
He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

When You’re Out to Fix Bottlenecks, Be Sure You’re Able to Distinguish Them From System Failures and Slow Spots Bottlenecks are likely to be lurking in your application. Here’s how you as a performance tester can find them. This article first appeared in Software Test & Performance, May 2005. So you found an odd pattern ...
There are many ways to approach test design. These approaches range from checklists to very precise algorithms in which test conditions are combined to achieve the most efficiency in testing. There are situations, such as in testing mobile applications, complex systems and cyber security, where tests need to be creative, cover a lot of functionality, ...
Has this ever happened to you: You’ve been testing for a while, perhaps building off of a branch, only to find out that, after all of this time, there is something big wrong. It’s a bad build and now you have to go backwards, fix something, and get a new build. Basically, you just wasted ...
Test plans have a bad reputation, and perhaps, they deserve it! There’s no beating around the bush. But times have changed. Systems are no longer “black boxes” where QA Teams are separated from design, input, and architecture. Test teams are much more technically savvy and knowledgeable about their systems, beyond domain knowledge. This was an old ...
  Explore It! is one of the very best software testing books ever written. It is packed with great ideas and Elisabeth Hendrickson’s writing style makes it very enjoyable to read. Hendrickson has a well-deserved reputation in the global software testing community as someone who has the enviable ability to clearly communicate highly-practical, well-thought-out ideas. ...
Jeff Offutt – Professor of Software Engineering in the Volgenau School of Information Technology at George Mason University – homepage – and editor-in-chief of Wiley’s journal of Software Testing, Verification and Reliability, LogiGear: How did you get into software testing? What do you find interesting about it? Professor Offutt: When I started college I didn’t ...
People who follow me on twitter or via my blog might be aware that I have a wide range of interests in areas outside my normal testing job. I like to research and learn different things, especially psychology and see if it may benefit and improve my skills and approaches during my normal testing job. ...
Regardless of the method you choose, simply spending some time thinking about good test design before writing the first test case will have a very high payback down the line, both in the quality and the efficiency of the tests. Test design is the single biggest contributor to success in software testing and its also ...
Companies generally consider the software they own, whether it is created in-house or acquired, as an asset (something that could appear on the balance sheet). The production of software impacts the profit and loss accounts for the year it is produced: The resources used to produce the software result in costs, and methods, tools, or ...
Introduction Many companies have come to realize that software testing is much more than a task that happens at the end of a software development cycle. They have come to understand that software testing is a strategic imperative and a discipline that can have a substantial impact on the success of an organization that develops ...
This article was developed from concepts in the book Global Software Test Automation: Discussion of Software Testing for Executives. Article Synopsis There are many misconceptions about Software Testing. This article deals with the 5 most common misconceptions about how Software Testing differs from other testing. Five Common Misconceptions Some of the most common misconceptions about ...
With this edition of LogiGear Magazine, we introduce a new feature, Mind Map. A mind map is a diagram, usually devoted to a single concept, used to visually organize related information, often in a hierarchical or interconnected, web-like fashion. This edition’s mind map, created by Sudhamshu Rao, focuses on tools that are available to help ...

One thought on “Same or Different? Retrospectives and Post-Mortems

  1. 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.

Leave a Reply

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

Stay in the loop with the lastest
software testing news

Subscribe