Analytics/ScrumRetrospective

=Status= This is a proposal on how the Analytics Team runs its Scrum Retrospectives. This is not yet a process adopted by the team, these are my personal thoughts.

=Types of Retrospectives= I think we need two types of retrospectives: Regardless of the type of retrospective, we need a facilitator who runs the retrospective and does not participate with the contents. We can choose case-by-case who should do this.
 * 1) The general retrospective where we identify process-improvements, improve team happiness and focus on making the team more mature.
 * 2) The post-mortem retrospective where we dive deep into a card, an epic, dataloss, prolonged breakdown of a service -- basically bigger issues that either affected our customers or we feel we can draw valuable lessons from it.

=The general retrospective= At the end of each sprint, usually after the Sprint Planning, we do our retrospective. To decide what we should discuss we could use the following approach:
 * On an etherpad, each team member lists the topics that he/she feels are worthy to reflect on. This should take between 3 and 5 minutes.
 * Next, each team member has 2 pluses (+) that can be assigned to any topic, you can assign two pluses to a single topic
 * The two topics that have the most pluses will be discussed.
 * Each topic is timeboxed at 30 minutes.
 * In case of a tie, discuss the three topics and adjust the timebox accordingly.

=The post-mortem retrospective AKA The Three R's=

Regret
This is the first and easy but important step -- recognize the issue, apologize to the affected customers and explain what happened. If the explanation on what happened depends on doing the five whys then just inform the customer(s) and recognize that an issue is affecting them and that action is being taken.

Reason
To uncover the reason we could use the five why's methodology. The 5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. Five is a rule of thumb -- you should keep asking why as long as it's giving meaningful answers.

Remedy
After having conducted the 5 why's one or more remedies will become evident. The team should commit to a particular remedy, once that has happened the post-mortem can be finished.

=Example=

=References= Some background reading on 5 whys and some cases:
 * http://www.startuplessonslearned.com/2008/11/five-whys.html
 * http://www.ustream.tv/recorded/27482093/highlight/310486
 * http://dev.hubspot.com/blog/bid/64771/Post-Mortems-at-HubSpot-What-I-Learned-From-250-Whys
 * http://www.joelonsoftware.com/items/2008/01/22.html