A Successful Retrospective

Someone asked me when do you know if you just led a successful retrospective.

My first reaction was that I will have to think and come up with some metrics which optimize the complete value chain. However, I started answering sooner than later. I stopped in between, reflected and continued. On the flight back, I reflected again on what I said. I thought it made sense. Let me know what do you think?

An effective or successful retrospective should have the following characteristics “come out”:

• No one should come out of the retrospective with ill feeling or negative thoughts towards anyone.
• No one should come out of the retrospective thinking they have not been heard properly.
• No one should come out of the retrospective saying they are not a party to this decision.
• No one should feel that the real reasons or suggestions did not come out.
• The team (and PO – if he/ she was present in the meeting) should be buzzing with enthusiasm in being part of something unique.
• The team (and PO – if he/ she was present in the meeting) should come out of the retrospective with more understanding about each others roles, expectations and requirements.

I think this made a good checklist – mentally, for a Scrum Coach.

Scrum Exposes Bad Processes and Obstacles

In our last post, we discussed the Agile Retrospective technique of Start, Stop, Continue or SSC. In this, post we discuss a technique first tried by Pete Deemer [CST, co-leader of Yahoo's implementation of Scrum].

Often, as the end of a sprint, the team comes back and says things like

• Its more stressful in Agile
• Things are worse than before
• Agile does not work
• We were better off before

If as a Process Coach or Scrum Master you hear something like this, you can try this in your retrospectives:

1. Ask the team to collectively come up with a list of things they thing are better than before/ is working well and also what is not working well/ worse than before. So, you have two lists : Better and Worse.
2. Now ask each member to mark each item on both the lists from three possible options : Caused by Scrum [C]/ Agile, Exposed/ Made Visible by Scrum or Agile [E], Does not relate to Scrum/ Agile [U].
3. Compile the score and let there be pin drop silence in the retrospective.
4. The team may find a lot of C’s on the “What’s Working Well or is Better than Before” side of the board, and a lot of E’s on the “What Could Work Better or What is Worse than Before ”; this is good news, even if the “What Could Work Better” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.
5. The team’s opinion and acceptance of Agile/ Scrum would have undergone a complete 180 degrees turn.

It is often useful to keep a snapshot of the whiteboard where these lists are maintained and keep revisiting them in each of the Retrospectives. This is especially useful for the teams which are transitioning to Scrum or Agile way of working.

Agile Retrospectives Start Stop Continue

Revisiting the discussion on agile retrospectives, it is recognized by some as the single most effective practice/ ceremony of Agile. This could be because this exercise:

1. Brings the team together
2. The team inspects what it has been doing
3. The team tries to adapt for better results

On a score of 04 based on Agile Manifesto, Agile Retrospectives would score a 02. They are about individuals and interactions and help the team respond to change. In addition, Agile Retrospectives help the team focus on 02 other principles of the Agile Manifesto : Customer Collaboration and Working Software.

There are various approaches in conducting Agile Retrospectives. One of the most common approach that is advocated by many coaches is “Start, Stop, Continue”. A very simple approach, this type of retrospective is usually conducted as follows:

1. All team members make 3 lists – what is working well and they should Continue doing, what is not working well and should be stopped, and what is something that can be explored/ Started.

2. One-by-one everyone adds their points to a central whiteboard/ list. They can do a plus 1 if what they want is already on the list.

3. After everyone has completed this, the team picks up the items with most “plus 1″.

4. They commit to “some” or “all” items in the 03 lists – Start List, Stop List, Continue List.

5. In the next retrospective, they go back to this list and evaluate how they have done [this can be done in a variety of ways too - everyone votes on whether they were successful in implementing something or not and after this a new Start, Stop, Continue List is drawn].

6. Some people like to keep it mechanical – vote and decide. Others like a lot of brainstorming, discussions and debates. Its useful to have debate on what you are planning to do. The only downside of debates in retrospectives is that more powerful or vociferous attendees may overpower others. Hence, the Scrum Master has to be really good.

This is a relatively simple approach and helps the team inspect and adapt continuously.

P.S. If you are in India, and haven’t taken this “Are we Really Agile Survey” then, I recommend you do so right away : http://www.surveymonkey.com/s.aspx?sm=uFtT7z80mHpM7hGvLFJtZg_3d_3d [it will only take a couple of minutes and is straight forward multiple choice survey].

Next Group – Session VI

This session was not about Agile practices but an understanding of what makes Agile work. It was suitably titled “Agile Thinking”. Agile Thinking focussed on retorspectives/ root cause analysis, energized environment and informative workplace. We focussed on how having the right information at the right time for the right people is key to being Agile. Another focus was on understanding how motivation, energy and intrinsic desire to innovate is the key to people delivering good quality output. We also discussed how having fun in the workplace was one of the key requirements for an energized workplace. Finally we focussed on how retrospectives can enable people to focus on the right things. The root cause analysis was discussed with two live examples as a technique to unearth the causes of problems/ obstacles.

Ours has traditionally been an organization which focusses on people sitting late as a sign of their hardwork. Focussing on energizing workplace allowed participants to come up with their suggestions on how to organize their lifestyles. One more important part of the session was a live use of root cause analysis.

One of our projects had been run under a lot of on the fly requirements, aggressive deadlines, unpredictable customer behavior and as you would know – lot of stress. As soon as the beta went live, customers registered on the website right, left and center. The website had too many bugs, feature requests, support emails and more importantly a harried/ stressed out staff.

1. We started with some symptoms first. The main one was “It was difficult client to manage”.
2. So we asked the first Why?
3. He was difficult because he was an intermediate client who was serving an external client and was communicating deadlines to them which we were not aware of. Also, he was unreasonable most of the time.
4. We asked the second why for the second part of above cause
5. He was unreasonable because he had an unstable mind and thinks of ideas all the time making our efforts unstable.
6. We asked the third why
7. We had coded in hurry so our architecture was not such that we could support rapid UI changes without affecting the underlying logic. And we were ourselves just following the client instructions.
8. We asked the fourth why
9. This was amongst our first dot.Net projects and the project was also domain specific.

At this point we thought we would do some SSC [Start/ Stop/ Continue] and came up with the following list:

1. Start to do:
a. Have better understanding of the end client deadlines
b. Refactor mercilessely and adhere to coding standards come what may
c. Start thinking about UI designs

2. Stop to do:
a. Stop coding in hurry and not obeying business layer logic
b. Refine the code in Data Access Layer

3. Continue to do:
a. Code fast and be as responsive as we have been
b. Follow the wireframing process

We intend to continue such exercises in future sessions as well.