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:
- require estimating;
- consume time and effort; and
- 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:
- Facilitate the Scrum Retrospective.
- Encourage the team to implement internal process improvements themselves.
- Update process artifacts like the Sprint Backlog or "Definition of Done" poster to reflect any changes agreed to by the team.
- 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.