InfoQ posted a great article recently on the challenges of adopting Scrum. The number one item on the list was lack of organizational learning and whether or not they had intended to rank those items in order of importance, lack of learning through retrospectives is one of 2 key issues with adopting Scrum.
I safely interchange lack of organizational learning through retrospectives and thinking Agile is easy as the top 2 issues with adopting Scrum. The Scrum process is in fact fairly simple, and there are some very simple approaches that agile coaches can use to facilitate learning across the organization.
Here are some quick tips, which include things I’ve used that have been met with success:
- Retrospectives are not optional: no matter what, have a retrospective at the end of every sprint. 3 simple questions: What Went Well? What Didn’t Go Well? What to Try Next Time?
- What to Try? Write a solution: Retrospectives are for learning and discussion without action is useless. We practice taking each “What to try” sticky and writing an action to address it. We then prioritize and agree to include this solution with the next sprint.
- Too much to remember at the end of the sprint? Keep a log: This tip is from an article I read about retrospectives of which the link eludes me. Write a sticky for each day in the sprint (IE: Day 1, Day 2, Day 3…Day N), stick it on the wall and provide red, green and yellow stickies for the team to write on. When something good or bad happens, write it down on the appropriate colour sticky. If a good idea pops up, write it on a yellow one.
- Scrub your solutions: At the start of the retrospective, briefly chat about the solutions you wanted to try and gauge the output. Was the solution obtained? Is it still relevant?
- Feed retrospective info up to management: Be transparent. Scrum surfaces issues quickly and the sooner management knows about it the better. This implies there is organizational trust but regardless, hiding problems to management is not a good thing to do. If management doesn’t get it or thinks scrum is failing because there are too many problems, they need to be coached more closely.
- Validate “What didn’t go well” items: People like to complain. It’s human nature and oh so fun! Retrospectives are not glorified bitching sessions and way to nip this in the bud is have each team member say something that didn’t go well out loud and let the team judge whether or not it’s a real problem.
These are a few techniques I’ve used during retrospectives and they can be very effective when used properly. The key is to introduce different techniques when needed or when your retrospectives start getting stale.
I’d love to hear your thoughts on other techniques you’ve used in your retrospectives, after all, it’s all about learning right?