Retrospectives in Retrospect

“You’re wasting your money,” my mentor warned. “Scrum is not something you can master in a weekend. That certification will be worth the paper it’s printed on.”

I was working retail, making $12 an hour, and I had just put down $1000 for a 2-day course to become a Certified ScrumMaster. And he was right. That certification wasn’t worth anything.

It’s what I did with it afterward that had value. And retrospectives played the starring role.

I was a year into my self-driven journey to learn how to develop software. I had a few unofficial mentors and had some powerful experiences with pair programming. I was just beginning to put together real apps on GitHub and even contribute to projects in the world of open source software —

But Holy Burt Reynolds’ Mustache,

I really- absolutely- super-duper could not afford an expense like that! I couldn’t even afford food. I was eating ketchup packets on my lunch breaks. It was a good day when someone left a bag of chips in the break room. So what was I doing taking this insane financial risk?

Psychologically, something interesting happens to you when you shell out money you don’t have on a risk like that. You squeeze out every last drop of value you can from it. And that’s what I did. I took the session’s post it notes and sharpies. I still have them. I took every un-eaten vegetarian sandwich home too. I ate good that week. And more than anything else, I hung on every word the instructor said. I made certain I understood every single concept, and that I could implement the entire process myself.

And I did that too. I implemented the Scrum process, every single part, on my personal software-learning endeavor. I played every part, the Product Owner, the Dev Team, the ScrumMaster. I conducted all the rituals. Sprint Planning, Daily Stand-ups, Backlog Grooming, Reviews, and Retrospectives.

Did I mention that certification was expensive? Because it was. It was really expensive.

But it was also a serious booster to my development. Three months later, I was getting serious interviews from tech companies. Six months after that I was awarded an Apprenticeship at 8th Light.

Retrospectives

At the end of every week, right after the review of what I had accomplished, I would write a retrospective. I can emphatically say it was that weekly retrospective that caused my success. The review was powerful too. It allowed me an opportunity to focus the relevance of my product. But the retrospective allowed me a weekly opportunity to focus the effectiveness of how I made that product. Retrospectives allowed me to improve my process.

It may seem obvious, but it needs to be said: good products are 100% dependent on good processes. You can’t have a good product without first having a good way to make that product.

Sure, if you ignore your process, you might, by blind luck, happen to make a good product. It’s also possible to mash the keyboard and by blind luck produce the manuscript to Pride and Prejudice. Even if you do manage to win that entropy’s lottery, there will certainly not be a repeat.

You don’t sell products.
You sell the products of your process.
Your process is your product!

And retrospectives help you improve your process.

I can’t overstate how vital it is to include frequent and regularly-timed retrospectives as part of your craft.

In a team, a retrospective is a meeting that happens after the product has been reviewed, demonstrated and approved by the product owner. It happens after every sprint.

In a personal scrum, a retrospective is written down like a journal entry. I use a markdown file on GitHub for this, but you might have your own tool. The important thing is to always do it. Retrospectives should be conducted regularly, like showering: Once a week, whether you need it or not.

Here’s how to retrospect:

1. List some good and bad things that happened. The list doesn’t have to be exhaustive.
2. Drill down. Repeatedly answer the question “why?” until you get to the root cause of each. Typically, this takes five whys. In the case of good things, the root cause is a strength. It needs to be protected and amplified. In the case of a bad thing, the root cause is a blocker and needs to either be removed, or treated as a bottleneck, the center of gravity around which your process flows. Sound mysterious? Read The Goal.
3. Finally, come up with a short list of changes to your process from the insights you just gathered.
4. Actually do the changes.
5. Repeat next week. (If you didn’t do the changes, list that as one of the bad things.)

This process allowed me to identify strengths and utilize them fully. It also allowed me to remove or control barriers to my success. Even more so, It gave me a realistic picture of my capabilities. This allowed me to estimate better and set more achievable commitments in the next week.

Without this, I’d easily take my strengths for granted or mistakenly throw them away. In either case it would have been hard to grow them. I’d also be continuously and chronically tripped-up by the same problems over and over. Finally, my goals and self-image would be distorted. I’d fail to make good decisions in setting the right kinds of goals, and then fail to achieve those goals.

Retrospectives in retrospect

Now it’s been nearly two years since I started scrumming. I’ve scrummed myself. I have observed teams scrumming well. I have observed teams not scrumming well. And I feel it’s time to have a retrospective about the value of retrospectives.

Fill this out for your situation:

Bad thing: The Retrospective is an element of scrum that is getting dropped.

Why? Answer 1: _________

Why Answer1? Answer 2:_________

Why Answer 2? Answer 3:_________

Why Answer 3? Answer 4:_________

Why Answer 4? Root Cause:_________

Process change to try:

Something to consider while filling this out: If you find yourself not falling in love with retrospectives, it might be your unexamined assumptions that are getting in the way. Here are some common mistakes around retrospectives:

Retrospectives are not performance reviews.

In a performance review, a manager sits down with an employee and tells her what she’s good and bad at. Then the manager and the employee develop a plan for improvement. Finally anything said in the meeting will have a direct impact of the employee’s salary and career trajectory.

This is not what you want to do for a retrospective. Retrospectives lose their value if one person, such as a manager, dictates to the team what will be improved. It wastes the group’s combined years of experience and puts the onus of process improvement squarely on the shoulders of the manager, the person in the room with the least immediate context and front-line experience on the project.

It can be a tough mindset to switch, but scrum is a self-organizing framework of peers, not a boss-employee dynamic. This means that you trust your team to direct their own improvements. That trust is built through lots of communication and openness both from yourself and the team. If you are a manager, definitely attend. You are part of the team. But do not take it over.

And certainly don’t tie job security, pay, or career advancement to the retrospective. If you do, your team will be encouraged to avoid risks like speaking about what’s actually wrong. You won’t get process improvement that way. Retrospectives have to be a done in a safe space where the team feels comfortable speaking out. It’s not the time or place to carrot-and-stick the team. They need to have nothing to lose for speaking their mind. If that safe space is provided, your team will be enabled to courageously tackle the really hard problems.

Retrospectives are not gripe sessions.

The purpose of a retrospective is to give yourself a formal opportunity to improve your process and in doing so improve your product. However, for team members coming out of a boss-employee dynamic, retrospectives can get off track. When I was working as a retail salesperson at a boss-employee style company, it was very common for me to participate in gripe sessions. We had many excellent criticisms for our bosses. All of them were brutally insightful. The one thing we were sure about, however, is that our bosses would never hear it, nor would they care to act on them beyond reprimanding us for insubordination. This meant that our words had no consequence and we didn’t expect any.

While theses complaints we had were indeed getting right to the heart of the matter, because there was no chance of actual improvement, our criticisms became less and less constructive over time. Sure, it’s fun to poke fun at our inefficient process, or how our boss has his priorities backwards, but those kinds of complaints were not constructive, you couldn’t direct process improvement from them alone.

When you first start implementing a retrospective, and you’ve set it up so there is a safe space (no negative consequences for speaking your mind), you will likely find your team falls into this space. It’s because they’re out of practice when it comes to actually having control over their own destinies. Allow them to vent for a short time. It’s important to get those feelings off their chests. It will then be your job to start directing the conversation towards productive actionable items.

Over time, as the team sees their ideas actually implemented, they will start to take ownership of the process and you can step away and let them find their own way. But those first few meetings might be a little intense. It also helps if you try to balance the negative with the positive so that the room doesn’t become too heated. The team will be looking to you for how to behave so lead by example and don’t fall into the negativity spiral.

Retrospectives are not the blame game.

Like the case of mistaking a retrospective for a performance review, retrospectives should never be about pointing fingers and assigning blame. It should be agreed at the start of the meeting that the team assumes that everyone involved did exactly what they thought was best given the information they had at the time they had it.

The purpose of a retrospective is to improve the members of the team, and their ability to work together to make products. This is not the place to shame team members, or to make roster cuts. If you do those things you will not find your process improving. In fact, you’ll find it getting worse. Shaming people decreases trust across the group. With a loss of trust comes a loss of communication. That communication gap will breed inefficiencies which will worsen the team’s performance. Not to mention it hurts people’s feelings.

If you feel the team is beginning to point fingers, step in and gently remind everyone that they’re all here for the same goal and everyone did the best they could given the circumstances. Then proceed to ask why. Why did Timmy drop the ball? Steer the discussion back to finding a root cause in where the process broke down, not where a team member did.

Retrospectives are not post-mortems.

Post mortems happen after something goes wrong. Treating a retrospective like a post-mortem is like treating emergency visits to the dentist as you once-a year tooth-brushing session. By then it’s too late. Retrospectives can help catch problems before they become emergencies. If you do them right, you’ll never even know there would have been a problem at all.

One of the most important aspects of a retrospective is that it happens regularly and frequently. The retrospective is a formal opportunity to improve your process. If you don’t have them often, you deny yourself opportunities to improve. If you have them infrequently, then you all but forfeit the opportunity to improve.

Post-mortems are about figuring out what went wrong, but that’s only half of what a retrospective does. Retrospectives are also about identifying, protecting, and doing more of what went right. The human brain tends to weigh bad things heavier than good things. There have been studies that show you need 12 positive interactions with something to overcome 1 negative interaction. It’s natural that during a retrospective there will be a focus on the negative. It’s important to understand that bias and give more weight to the positives during the retrospective. The key thing is that there needs to be balance.

Retrospectives in Retrospect in retrospect

Performance reviews, gripe sessions, blame games, post mortems, each of these pitfalls has something in common: they assume a top-down command-and-control system of bosses who give orders and employees who take orders. That’s not what scrum is.

Scrum is a self-organizing, self-directing team of peers who all have a stake and a say in how to proceed. It is this concept that is the key differentiator of scrum. Without this paradigm switch, scrum won’t be more effective than what you already have in place. So how do you get that boss-employee dynamic out of your head?

As it turns out, when you conduct a personal scrum, it’s impossible to make that mistake. You are the whole team. Boss, employee, it’s all just you. You moving toward your goals and making improvements as you go.

You can’t have a boss-employee dynamic when there’s only one person on the team. For that reason alone, I would recommend every member of a scrum team also take some time to conduct a personal scrum. It’s perfect for side projects, and it circumvents the misinterpretations caused by unexamined assumptions inherited from the old boss-employee paradygm.

Personal or in a team, it’s the retrospective which is the real star of the scrum. Retrospectives allow you to improve. So don’t skip retrospectives. They’re really important to your success.

Did I mention they’re important? Because they are. Retrospectives are really important.

Oh yeah, and go fill out that retrospective form about not having retrospectives. You’ll be glad you did.