Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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?
share|improve this question
    
"I was told" by whom? What person or role is dictating your team's internal practice? The Sprint Backlog and its artifacts belong to the team and no one else. –  CodeGnome Nov 8 '12 at 12:09
    
@CodeGnome - our retrospectives and standups are ran by project manager; he is SCRUM-certified; he told us that using our task board (it's an electronic one, Urban Turtle getting data from TFS) is messing up project planning process and should be avoided; since we have just one task board our retro items are not getting into the sprint backlog. –  Steve V Nov 8 '12 at 15:31

3 Answers 3

up vote 5 down vote accepted

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.

share|improve this answer
    
An alternative way to do retrospectives by Hakan Forss: hakanforss.wordpress.com/2012/04/25/… –  Zsolt Nov 2 '12 at 23:12

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.
share|improve this answer
    
> You can only implement it if there is real value in it for your team, otherwise they won't do it ============== they - means team? oh, they would (probably) do it - at least it looked that way when the idea has been discussed during the retro; but (I don't know why) we have no budget for these things, our product manager (he is running standups) will forget about our shiny ideas by next morning - and that's understandable since nothing has been placed on the task board; so we go back to square 1. –  Steve V Nov 8 '12 at 11:03
    
Yes, the team. I edited my response accordingly. I guess you'll have to convince him then to add it. At least, you should be able to add it to the sprint backlog for next sprint (or at least bring it up again during next sprint planning). –  Stephan Nov 8 '12 at 11:29
    
@SteveV If your Product Owner (or worse, a non-Scrum product manager) is running your stand-ups, then you're already off in the weeds. This is not Scrum, and it's unlikely to be agile. –  CodeGnome Nov 8 '12 at 12:14
    
@CodeGnome he is project manager (we have another person as product owner); he is a scrum-master. I think we have some kind of "corporate" version of SCRUM (if it makes any sense) –  Steve V Nov 8 '12 at 15:29

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.

share|improve this answer
    
I am not a Scrum Master (but would like to become one someday); what is the difference between Sprint Backlog and Product Backlog? I was always under impression that Sprint Backlog is part of Product Backlog -> it's impossible to add anything into Sprint Backlog without affecting Product Backlog ... –  Steve V Nov 8 '12 at 15:28
    
@SteveV that is correct, however sometimes the product owner and the team let improvement ideas to enter the sprint backlog. This approach violates the transparency principle, but practice has shown that this is the most efficient way to work with improvements. –  Zsolt Dec 9 '12 at 13:31
1  
@SteveV The two backlogs are completely different artifacts. Please ask this as a separate question if you want a more thorough answer. –  CodeGnome Dec 9 '12 at 15:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.