If you ask me, the retrospective is the most valuable ceremony that exists in Scrum practice. The concept of inspecting and adapting is one of the cores of Agile and without it, we would never get past the very basic level of efficiency. And that's just not very efficient.

I'm not going to prescribe a certain set of questions or even a specific format, but there are a few environmental things and practices that you can employ to make your retrospectives more effective.

Send the Invitation to Everyone

You and your team members are not the only people affected by your work. Stakeholders, external product owners, other teams that you collaborate with and anyone else that might have valuable input should be invited to your retrospective.

This isn't something I would recommend doing for each and every retrospective (this can make for a pretty full room), but at the end of a major release or project (or any other time that makes sense to your team) could be the perfect opportunity to hear an outside perspective on your team's performance. These "outsiders" may be able to provide valuable insight into different processes or practices that you could employ to further improve your team's work. It's also a good time to hear about the things you did right throughout the project so your team hears some validation from someone other than the Scrum Master.

In a normal retrospective, I recommend inviting the entire team. I'm not just talking about the engineers. Bring in your Product Owner! If you only hear from the engineers, you're only getting half the picture. If you're practicing Scrum, the Product Owner is part of the team and should be included in these inspect/adapt discussions.

Open Communication

This is such an abstract concept, but it's so vital to the spirit of the retrospective. Open communication is a two-way street. Team members need to be willing to talk and listen. Sometimes, people are going to feel beat up in a retrospective after a particularly painful sprint. This is the time when they need to listen to the feedback given by their peers the most. I know it's hard to listen to negative feedback, but as long as it's delivered a constructive way (remember this post where I said that Agile can't fix your people problems?), nothing but good can come from taking it in and making changes in yourself or your team.

Defensiveness is not allowed.

Active participation is encouraged.

Follow up!

What's the point of having an awesome retrospective discussion, if you don't change anything because of it? What have you just accomplished?

Hear this: If you say you're going to improve by doing X and then never follow up on X, you have done nothing but waste everyone's time.

As a team, decide what you want to change, document it and make it visible! Post it on the wall in your team's work area and talk about it throughout the sprint. Make it front of mind. Then, when your next retrospective comes around, ask the team how they did! Do they feel like they accomplished what they agreed to? Do they feel they did everything in their power to improve in that area? Can we consider the action item closed or do we need to continue to work on it?

-------

So, use whatever format works for you team. Change it up. Have fun with the retrospective. But, don't lose the spirit of the retrospective. The point is to Inspect and Adapt. Neither of these things feel natural in a group setting, but they are vital to the health of an Agile team.

What other advice do you have for teams struggling with their retrospectives?

Technical debt (or tech debt) is a concept that is often misunderstood by those new to Agile development (and sometimes those that are not so new). It is a common misconception that tech debt is that "little bug" found in your code right before the end of the sprint that you don't have time to fix. That's absolutely not the case. That's a bug...a defect, plain and simple.

Let's break down exactly what technical debt is in order to better understand the concept. Ward Cunningham first coined the phrase back in 1992 when he explained the refactoring process using the metaphor of debt in a paper on the WyCash Portfolio Management System.

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." - Ward Cunningham

Keep in mind that he's not saying that it is acceptable to allow a few bugs into the code as long as you can ship it promptly. He's saying that taking a "quick and dirty" approach that gets the job done with the intent of going back to clean up after yourself allows the product to get to market quickly.

photo credit: Cool Syntax Highlighting via photopin (license)

A "bug" is something that doesn't work as intended...something that makes your Definition of Done (you do have a Definition of Done, right?) not complete. I'll assume that one part of your Definition of Done is that your code passes all tests. If that is the case (and it should be), then that user story is not done. If you say "That bug isn't that big of a deal, we'll fix it in the next release," that isn't technical debt. That's a bug, my friend.

Ideally, we would always have time to build out a future-conscious design that may take longer to implement, but is the cleaner solution. However, this isn't always possible with time constraints and, let's be honest, we don't always (almost never) have a clear vision of the future state of the system that would allow us to know exactly how to architect it in a way that is future-proof.

Keeping with the debt metaphor, the longer technical debt remains without being refactored, you gain "interest" on that debt. That means that, if left alone, your once minor tech debt will eventually become a huge issue that impedes future development efforts. Tech debt needs to be addressed and "paid off" as quickly as possible.

One of the easiest ways to manage your tech debt is to devote a certain percentage of development efforts to refactoring, or "paying off," tech debt. A common practice in Agile development is to devote 20% of development time to tech debt. This might mean that you devote every 5th sprint to tech debt or that you include 1 tech debt user story for every 4 feature stories in each sprint. How you do it doesn't necessarily matter. What's important is that it gets done.

How does your team handle tech debt? Have ever experienced a case where tech debt was left unchecked and turned into a project in and of itself?

This is just me sharing a frustration of mine. A professional pet peeve, if you will.

A few years ago, I went to a 3 day course which was described as an Agile Boot Camp. Since the company I was with at that time was in the infant stages of an Agile transformation strategy, this seemed like a great course for the project management team (all 3 of us).

The boot camp was full of great information and really got us pumped about what we were about to do. We spent an entire day talking about sprint ceremonies and how to use them properly. We discussed user stories and their relationship to epics, features, et cetera.

The class was awesome, but there was one major problem which I didn't really notice at the time....The class wasn't an Agile boot camp; It was a Scrum Boot Camp.

Agile is so much more than just Scrum. It's so much more than Kanban or XP or SAFe.

Agile is the why. The framework (such as Scrum or XP) is the how.

Just the other day, Mike Cottmeyer wrote a really great post about why frameworks and methodologies don't matter. If someone asks you to describe Agile and you give them an overview of Scrum, you're really short-changing them by giving such a limiting view of the Agile Manifesto, which is the set of guiding principles for Agile.

Agile is a mindset and a way of thinking. The Agile values can certainly be implemented through the use of a framework like Scrum, but Scrum is not Agile!

If you were in an elevator with a colleague and they asked you, "What is Agile?" How would you explain Agile to them in 1 or 2 sentences? Leave me a comment with your "elevator pitch."