How should we implement items from Sprint Retrospectives?

Question

Every two weeks we have our Scrum retrospective meeting and everything seems to be great, because we are getting lots of ideas. However, the problem is that these ideas are almost never actually implemented.

I was pushing hard to place all these actionable items--the result of the retrospective meetings--on our Scrum board, but I was told that it is for product-related tasks only. I tried to argue that team development is also a product, but it didn't work.

So, my questions are:

• How do you implement items from retrospectives?
• Do you have any budget (time/money/etc) for such things?
• How often do you follow up?

Answer 1

I recommend to change the focus of your retrospectives. Instead of finding ideas, try to focus on how to implement a single idea. Let's say, you have three parts of the meeting: finding ideas, what is the next step, and how to implement that step.

In the first part, you do the idea collecting - nothing new here -, but in the second part you pick only one idea, which the team will implement during the next Sprint. In the third part, you do a planning meeting like session on how to implement that idea and bring the result - the tasks - to your Scrum board. It is highly recommended to timebox these parts so that you have enough time for the third part.

With this approach you have your focus and tracking. There is no need to talk about the progress of the idea during on a daily basis, but it can help a lot. Putting the created "idea tasks" into the Sprint Backlog with a different color can also help, but this trick is team dependent.

If you don't have the improvements on your Scrum Board, they won't be visible, and this means that they don't exist (yes, you can have improvements on your Scrum board).

Budgeting is an interesting question. A good Product Owner knows, that continuous improvements are crucial in Scrum - the framework is about continuous improvement - so it is not a question whether to have them or not. If you still have trouble, then you need to do more coaching and help people understand the importance of continuous improvements on each level. Doing them off the record is not a good idea, because then there is no real transparency any more, which eventually will lead to mistrust between the Product Owner and the Scrum Team.

Answer 2

Retrospectives are for Process Improvement

The purpose of a retrospective in Scrum is to "inspect and adapt" the team's process. It's not intended as a brainstorming session for product ideas, or for generating user stories that people want to see on the task board---it's about improving the team's internal process to do more of what works and less of what doesn't.

For example, your team may decide they need to revamp the "definition of done." Or perhaps they decide that they need to refactor the way they branch and merge the source code, or need to add a continuous integration server to the work-flow.

Anything internal to the team goes into the Sprint Backlog (not the Product Backlog) and therefore doesn't require any consensus outside the team. However, if your retrospective identifies process issues that are externalities (e.g. the need for appropriations for a new CI server, or ongoing failures related to inter-team hand-offs) then of course the larger organization will need to be made aware of the issues.

Make Issues Visible

The retrospective is about making issues visible, and allowing the team the leeway to self-organize around a solution. However, if your corporate culture doesn't truly allow the Scrum team to solve problems, the team has the right and the responsibility to raise the visibility of the issue, and then drop it squarely in management's lap.

For example, if the lack of a CI server is identified as a process bottleneck by your team, then this issue needs to be raised with the organization. If those holding the purse strings say "do without," then that's a business decision they need to live with---the team's job is simply to make the cost of that business decision fully visible.

That means that no one works unpaid overtime manually running integration tests, or does integration work "off the board." If it's work, it goes on the board!

If the organization says no to CI, then merging and integration testing simply become explicit stories on the Sprint Backlog that:

1. require estimating;
2. consume time and effort; and
3. redirect resources, man-hours, and story points away from new features.

The fact that these additional tasks reduce capacity for Product Backlog items is neither good nor bad; it's simply a natural consequence of the business decision, and as long as it is transparent and visible to both the team and the organization, the responsibility to accept reduced capacity or to change the situation belongs solely to management.

The Scrum Master's Role

The role of the Scrum Master in all of this is to:

1. Facilitate the Scrum Retrospective.
2. Encourage the team to implement internal process improvements themselves.
3. Update process artifacts like the Sprint Backlog or "Definition of Done" poster to reflect any changes agreed to by the team.
4. Facilitate communication with the outside organization when issues are broader than the team's internal process.

And that's it. You're not a baby-sitter. Your job isn't to "manage" the results of the retrospective, to chase after people to make sure they're implementing changes, or anything else that smacks of micro-management. You are a facilitator, a process referee, and a coach; don't lose site of the core role that enables Scrum as a process to work smoothly.

Answer 3

I see and experience only two types of improvements that come out of retrospectives (or any other Lessons Learned session for that matter):

• The improvement idea can be handled within your team (and thus your budget) and should only be implemented if it will result in a direct benefit for your team and thus on the overall progress of your project. Follow-up starts next stand-up meeting. You can only implement it if there is real value in it for your team, otherwise the team won't do it. In that case, let it drop.

When succesful, you can distribute this Lesson Learned to the rest of your organisation.

• The improvement is outside the authority or capacity of your team (eg organisational processes, or tool-dependent or ...). Here you cannot do anything except try to convince others (eg your manager) that it would greatly improve your (and possibly other) teams, reduce cost, fasten delivery etc. This is outside your project budget, unless it is decided that you can add this as an additional scope item to do by your team, taking in mind the impact on the available budget. Otherwise it is completely outside your team scope and you can only remind the relevant people of its' importance (with new cases, additional numbers of waste etc.) and check up regularly if there is any progress.