Contents
Look Back to Move Forward
“Lessons learned” meetings, also known by the gorier phrase “post-mortems,” were part of project management long before any of the Agile methods were developed. The Project Management Body of Knowledge (PMBOK) repeatedly mentions “lessons learned.” However, it points to a benefit of Agile when it says, “Large and complex projects are frequently executed in an iterative fashion to reduce risk by allowing the team to incorporate feedback and lessons learned between iterations.”[1] In Scrum, this occurs in the Sprint Retrospective Ceremony. The Retro is where a key part of self-direction occurs, when the team changes its processes to meet its objectives and needs.
Remember that the Retro is restricted to team members only. Stakeholders have an opportunity for input during the Demo. The Retro is a safe place to bring up concerns about the stakeholders, or the company, or the customers, and fuss about FuSca, for that matter. Playing on an old advertising line about Las Vegas, I like to say, “What is said in the Retro, stays in the Retro.” Only with the team’s permission should anyone convey Retro information outside of the team, generally as part of an action item or a story written as a result of the meeting.
Bear in mind that the Retro is primarily about improving the team, by changing what the team has control over. Some griping about a broken machine another team controls is human and can be recorded. But unless the team thinks it was a maintenance issue or the machine should be replaced—issues the team can address by requesting changes—quickly move the focus to the team’s interactions, Scrum practices, tools, and organization. Especially note changes made after previous Retros. Are they working or not?
In covering the three questions below, be sure you address the Agile Performance Standards. The percentage of stories accepted will be part of every Retro, either as a “went right” or a “went wrong.” Although I’ve had teams complete 100% of stories in their first sprint, more commonly the figure is well below that. Frankly, in a team’s first sprint, I’m happy if any stories get accepted! Whatever the acceptance percentage is, it sets the benchmark for the team’s second sprint. From that point forward, you have hard numbers to work from. Each time you get a higher percentage completed, that progress should be celebrated. Once you are hitting 100% most of the time, increasing the Sprint Goal may be possible. The Retro is the best place to discuss that, because you already have plenty to do during the Planning Ceremony.
This, too, is where you address defects. Even if you got all of them fixed—a “went right”—there still may be room for improvement. Is there a way to reduce defects created during the sprint? What caused any standalone defects reported? How did escapes happen?
And don’t forget the “blaming” standard. It is okay, indeed honorable, for an individual to take responsibility for a mistake they made. This also is the proverbial “safe place” for members to raise concerns about people following the team rules. Otherwise, people should not be pointing fingers at each other. And in addressing problems, the team needs to focus on what it can control instead of looking for someone to point its collective finger at. Accept what you can’t change, and change the rest.
Ask Three Questions
Create a Place for the Answers
Before the first Retro, the Facilitator needs to set up a place to capture the team’s Retrospective and other agreements not related to specific stories. For teams with access to computers, create a page in any tool your company provides for giving multiple people access to change a document. This can be as simple as a shared folder on a network or a wiki, or one of the many document management apps for this purpose. Other types of teams may need document printouts kept somewhere near their paper tracker.
If at all possible, this location should be one you can limit to the team members, like a page in a teamwork app only team members can view (and edit). Like the meeting, the Retro results are private to the team.
Many teams find it helpful for the Facilitator to create the page or section for a given Retro a day ahead. That way people who like to think things through ahead of time, and those wanting to jot ideas as they think of them, can do so efficiently. In that case, I ask them to add their initials to their comments so we know who to ask about each during the Retro. As in other Agile documentation I’ve described, you are not looking for paragraphs, or even complete sentences. I always use bullet points of one sentence (or partial sentence) each.
As in scrums, Retros in FuSca answer just three questions:
- What went right?
- What went wrong?
- What can we do differently?
⇒ Steps: Retrospective Preparation
What Went Right?
The Retro starts with the good stuff. Did the team’s percentage of accepted stories go up? Did the Customer have nice things to say in the Demo? Were problems in previous sprints avoided or reduced this time around? Were there specific examples of members helping each other in new ways? Did changes the team made to its Scrum or work processes work as hoped?
Ask anyone who added bullets beforehand to elaborate on their comments. Encourage everyone to add items, add to items, or suggest revisions. It’s also okay for people to disagree with an item and ask for its removal. As always, facilitate an agreement with the team. You want consensus on the entire list by the end of the Retro.
What Went Wrong?
Next discuss what could have gone better, asking questions like:
- If stories were not completed or accepted, why not?
- Are there Scrum practices the team used that did not seem to add much value for the effort?
- Did anyone feel especially stressed? When and why?
- Did communication flow okay within and outside of the team?
- What blockers arose, and how could you prevent that type in the future or clear them quicker?
- How did the task hand-offs go between members? What about work shared with other teams?
Be careful to prevent the “blame game.” You are not trying to find out who screwed up, because it was the whole team! One member may have fallen behind in his tasks, but the rest of the team failed to notice and offer help. Or maybe they didn’t challenge his capacity or estimates enough during the Planning Ceremony. Perhaps the story should have been split smaller during grooming. Did you put a story in the plan on the assumption a dependency would get cleared? Did a team your team was counting on know you were counting on it? Had they agreed to meet your deadline? Did you meet the deadline for getting your part done? Could your team have predicted a problem by putting more thinking into the risks, dependencies, and tasks?
You are probably sensing a pattern. Part of Full Scale agile is taking responsibility when things go wrong. In the vast majority of cases where stories are left incomplete, the team could have done something to identify and address the cause before or during the sprint. Predicting the future will always be an iffy proposition. But the more responsibility you take for your problems as a team, the more control you get over your own fate. Every team I worked with directly in teaching this method—dozens of them in different companies and industries—have learned to deliver 100% of their stories bug-free. Assuming your team consists of humans, it can, too.
I’ll pick on myself for an example. Early on I said I used Agile to stain the back deck of my house. During the half-hour I was waiting for a deck section to dry, after cleaning and before staining, I edited this section of the site content. Earlier in the day the weather forecast called for a sunny day, but clouds were now moving in. Before starting to stain, I decided to check again, and sure enough, thunderstorms were on their way. I thought of the previous paragraph as I carried the stain bucket and brushes back to the garage. “I could have checked the forecast again,” I said to myself in a mini-Retro, “knowing it could change in half a day.” I did so from then on.
Still, compassion is called for when teams don’t hit the Performance Standards:
- One team I worked with often had members getting invited by upper managers to mandatory meetings at the last minute. Had they set their capacities low enough to allow for this every sprint, their Sprint Goals would have been embarrassing! We couldn’t get the executives to stop, so the team sometimes missed the 100% goal due to that problem, and the stakeholders were understanding.
- Another team was cut in half partway into the sprint by a company layoff. That sprint they obviously did not reach their goal. But after a research sprint to change direction (all “spike stories“), they got Customer permission to switch to another project they could do with the remaining people and hit 100% the very next sprint!
- A service a team needed in order to complete an upgrade was supported by an non-agile organization. It went down just as the team started its five-hour upgrade effort—the other organization planned an upgrade to the service without telling anyone! The Customer was on the late-night call and agreed to stop the effort. The story was pulled out of the sprint commitment and the team was not punished for the failure. But they were understandably demoralized. This example shows the importance of business requirements. Had the service organization been agile and used them, the problem would have been avoided.
In short, try to strike a fair balance between responsibility and unfair expectations. Having some sprints fail due to unpredictable circumstances is inevitable, but that explanation needs to be rational, not rationalized.
What Can We Do Differently?
You now have the chance to address every “went wrong.” What caused the problem? Is it time to change a process, or do you want to wait another sprint or two and see how it goes? Often, especially with teams new to Scrum, it is just a matter of following the practices more closely. Is it possible people aren’t front-loading, or need to be even more conservative in their capacity and task estimates?
First let people answer the “do differently” question freely. Then look at each “went wrong” item and ensure you have addressed them all. As with any group decision, make sure either a story or action item has resulted from each unless the decision is to take no action. (Note that choice and the reason in the Retro documentation, in case there are future questions.) It is okay, also, to list possible changes you want to look at later.
Wrap Up
Review the “Do Differently” sections from the past several Retros. Did the team do what it said it would? When the answer is “no,” revisit that item to see whether it is still needed. Those that are may require action items to ensure they happen, or you might want to move them to the current Retro notes to keep them in mind during the next sprint.
Before ending the meeting, open up the discussion for any additions or changes the team wants in any section. One trick I use is to switch views when possible. Depending on the application you use, the page may look different in editing mode than it does in viewing mode (as wikis do). In that case, switch back to “view” mode. Sometimes seeing the text in a different format brings out points (or at least spelling errors!) the team missed before.
Either way, give the team a view of the whole list and ask for other changes. Only when silence or head-nodding confirms consensus with the list as written should you close the meeting.
When done, you will have something like this example from a new Scrum team’s first Retrospective:
⇒ Steps: Retrospective Ceremony
↑ The Sprint Process | ← Demonstrate Your Success | → Prepare for the New Sprint
[1] Project Management Body of Knowledge (Project Management Institute 2013).