Two woodcutters were assigned to chop wood in a forest. Both formed a team and started early and earnestly. Although working a distance from each other, they felt the competition to produce the best results.
On that first day, the first woodcutter heard his counterpart stop cutting before the day was really finished. He was surprised, but continued none-the-less. In the next few days, a similar thing happened. A couple of weeks passed. The first woodcutter paid a visit to the second one, confidently thinking that he has cut more wood since he had been working such full, long days. He was taken aback seeing that his counterpart has almost completed twice as much work. He asked, “How is that possible? I never stopped or took a rest, whereas you stopped many times!” The second woodcutter replied, “Yes, but I didn’t actually stop. Rather, I sharpened my axe, so that I could continue cutting better for the next day, the next week, and the weeks ahead.”
Perhaps many of us know this story of the two woodcutters and the key takeaway: “sharpen the axe once in a while and you get better results.” Stephen R. Covey slightly reworded the moral of the story eloquently in his book “The 7 Habits of Highly Effective People” by saying, “Sharpen the saw.”
Let’s apply this by thinking of a team of Agile practitioners working on a software product. The team has a number of generalizing specialists, who have skills spanning across coding, testing, integration, and deployment among others. They are cutting code instead of cutting wood, are testing the soundness of code instead of the solidness of wood, and so on.
Would you ask them to continue working week after week or month after month without ever sharpening their tools? I guess not.
Retrospectives and intraspectives in Agile development do exactly that. They sharpen the saw, or ask us to reflect, rethink, and act with renewed vigor. They provide a better understanding and also help us to work sustainably over a long period.
Retrospectives
The importance of taking the time for retrospection comes from one of the 12 core principles of the Agile Manifesto.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
In Agile, frequent retrospection is done in order to continually improve the effectiveness of the team, project, and organization. The retrospective process consists of two words:
- Retro – meaning recent past, and
- Perspective – meaning the way of looking at things.
Hence, you can say that the retrospective is about looking back or dealing with past events or situations for the purpose of improving in the future. You can define the retrospective process as:
A recurring workshop in which the team looks back on their work over a period, reflects upon it, and learns. The team applies this learning in future work to improve people, processes, and products.
One of the widely used iteration-based Agile frameworks is Scrum where every iteration is known as a Sprint. There is a Sprint Retrospective at the end of every Sprint, and it’s an opportunity for the team to inspect itself and create a plan for further improvements. The plan is preferably acted-upon in the next Sprint. Retrospectives are also applicable in flow based Lean-Agile frameworks, e.g., Kanban, where you can have retrospectives on-demand.
Types of Retrospectives
In iteration-based Agile development, a project is usually divided into releases and each release into various iterations. Hence, for Agile practitioners, there are three types of retrospectives:
- An Iteration Retrospective: Usually focused on the team involved in the iteration.
- A Release Retrospective: A wider perspective because it may involve other people in the organization who have contributed to the release, but are not part of the core team.
- A Project Retrospective: Also has a wider perspective, and is usually from an organizational point of view.
Retrospectives can happen in the following cases:
- When the team ships something. In a flow-based Agile (like the Kanban method), a release doesn’t happen during a specific time period. It can happen at any time.
- When more than a few weeks have passed since the last retrospective. Again, in a flow-based Agile process, there is no specific time a retrospective can happen. You can decide in such cases.
- When the team is stuck (i.e., the work items are not flowing through the team).
- When the team reaches a milestone.
Conducting Retrospectives
A retrospective is not a post-mortem meeting, nor should it be a dissection on what events happened wrongly or why. A retrospective should also not be a witch-hunt meeting to put blame on someone or some group. The key to a constructive successful retrospective is for all participants to adhere to the Retrospective Prime Directive, as noted by Norman Kerth, which says:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Four Key Questions
Considering the prime directive, there are four key questions in a retrospective, which can also be used when creating your meeting agenda:
- What did we do well, that if we don’t discuss we might forget?
(or what is going well?) - What did we learn?
- What should we do differently next time?
- What still puzzles us?
Look at the wording closely. We aren’t asking what went wrong, rather as the third question goes, we are asking what should be done differently next time.
Five Steps in a Retrospective
A retrospective, as noted, can happen as part of both iteration-based and flow-based Agile frameworks. A retrospective is a process, and it goes through a series of steps. See the figure below. It’s depicts a two-hour (120 minute) retrospective with time spread across the five steps of:
- Step 1 – Set the Stage
- Step 2 – Gather the Data
- Step 3 – Generate the Insights
- Step 4 – Decide What To Do
- Step 5 – Close the Retrospective
Let’s understand these steps.
Step 1: Set the Stage
Here the time box (how much time), goal (what you are going to do), approach (how you are going to do it), and work agreements or ground rules are set. If any particular Agile method is used, then the values of that method are announced. The principle of “Every voice and early” is followed, i.e., everyone should speak, and they should speak early. If they don’t speak early, then they may not speak at all!
Step 2: Gather Data
Once the stage has been set, the next step is to gather data. Start with hard data such as metrics, events that’ve happened, or stories completed. Create a visual record having events, story completion, date, etc. The visual is very powerful. Data doesn’t have emotions; therefore, ensure that you bring feelings into the data by asking questions such as, “When were the participants excited to come to work?”
Step 3: Generate Insights
After you have gathered the data, it’s time to evaluate, analyze the data, and provide insights. This step tells the “why” i.e., we generate meaningful insights from the data collected in the previous step. These insights help the team to work more effectively and efficiently – the main goal in any retrospective.
Step 4: Decide What to Do
This step reveals the “what to do” part or the planning part. If you have a long list of decision action items, choose a few, which the team can commit to doing – preferably in the next one or two iterations. A good way to have the action items implemented is to create story cards or backlog items and have them available in the product backlog. Ensure that you assign action items because it drives commitment.
Step 5: Close the Retrospective
In this step, you close the retrospective. When you close the retrospective, don’t forget to appreciate your team for the hard work done during the iteration (or release or project) and during the retrospective.
Retrospective Techniques
In each of these above steps, a number of techniques can be used. We will discuss a few of them.
Techniques to “Set the Stage”
1) Check in: In this technique, we hope that people put aside their concerns and participate in the retrospective articulating what they want from it. The retrospective leader asks only one question and each person answers in round robin fashion. The answers are usually in one or two words or a short phrase. Example questions can be:
“In a word or two, what you expect from the retrospective?” Or “What is one thing in your mind as we begin the retrospective?”
2) Explorer, Shopper, Vacationers, Prisoners (ESVP) Quiz: Let’s first understand what the letters in ESVP stand for.
- Explorers: Someone who is eager to know new ideas and insights.
- Shopper: The participant looks over all information, but is happy to go home with one useful new idea.
- Vacationers: The participant is not interested and happy to be left out.
- Prisoners: Someone who thinks that he or she has been forced to attend the meeting and should be doing something else.
In this exercise, each retrospective participant anonymously writes sown his or her position and puts it on a slip of paper or index card. Next, the leader takes the responses and put them into a histogram or a check sheet.
After the results have been collected, you should tear up the cards so that no one is worried about being tracked with handwriting analysis! With this information, you will have a good idea of how your audience feels about the retrospective. This exercise informs about the participants’ attitudes in particular.
Other techniques that can be used in the step of setting the stage are: Focus on/focus off, working agreements, or ground rules.
Techniques to “Gather Data”
1) Timeline: A timeline is used to stimulate memories of what happened in the time period that just passed. The retrospective participants write down memorable and meaningful events on sticky notes and paste them in chronological order on a board. A sample example is shown below, which in this case, is for an iteration.
2) Mad Sad Glad: Here you have three posters labeled – “Mad,” “Sad,” and “Glad.” You can also have color-coded cards or sticky notes. For example: red for mad, yellow for sad, and green for glad.
The team members then put the color-coded cards on the labelled posters and describe times during the project when they felt mad, sad, or glad. This exercise gets the “feeling facts” out on the table.
Other techniques that can be used in this step are: triple nickels, color coded dots, locate strengths, team radar, or like to like.
Techniques to “Generate Insights”
1) Force Field Analysis: This technique was originally used in a change management context (and also in risk management), but it can be adapted for retrospectives. Here, the team defines a desired state they want to achieve. Then, identifies the following:
- Driving forces (“forces of change”), which affects the desired state positively.
- Restraining forces (“forces against change”), which affect the desired state negatively.
- Factors that can influence reaching the desired state—either by increasing the strength of a supporting factor or by reducing the strength of an inhibiting one.
Utilize a white board and markers with this analytical technique.
2) Learning Matrix: In this case, participants look at the data generated from four perspectives by brainstorming on them quickly. This is a good technique to use if you are pressed for time. The four perspectives can be put on a flip-chart or white board, each in a quadrant, as depicted in the figure below.
Brainstorming, Ishikawa diagram, patterns and shifts, and the five whys are some of the other techniques that can be used in this step.
Techniques to “Decide What to Do”
1) Short Objects: This technique helps to discover differing perspectives on what the team members should or should not do, or should do more or less of. The team brainstorms and put their perspectives on three or two posters or flip charts. The titles of each could be:
- Same as/More of/Less of (SAMOLO)
- Stop Doing/Start Doing/Keep Doing (StoStaKee)
- Keep/Drop/Add
- What Worked Well/Do Differently Next Time (WWWDD)
- Smiley/Frowny
- Priority 1 issues receive four dots.
- Priority 2 issues receive three dots.
- Priority 3 issues receives two dots.
- Priority 4 issues received one dot.
The issues that have the most dots are chosen, and those should be focused on.
Other techniques that can be used in this step are: retrospective planning game, SMART (speciļ¬c, measurable, attainable, relevant, and timely) goals, and circle of questions.
Techniques to “Close the Retrospective”
1) +/Delta (Plus/Delta): This technique is used to retrospect on the ongoing retrospective and identify areas of strength and areas needing improvement. It starts with drawing a “T” on a flipchart or white board, divided the space into two parts: “+” and “delta.” The items that the team should do more of should be listed under “+” and ones that can be changed by the next retrospective are put under “delta,” which is the Greek alphabet meaning “change.”
2) Return On Time Invested (ROTI):
This technique generates feedback on the retrospective process itself and determines the effectiveness of the retrospective session from team members’ perspectives, by asking if the participants believe their time was spent well. You can use a scale rating system (“0” representing a lost cause and “5” indicating a very high return or the highest ROTI).
Other techniques that can be used in this step are: appreciation, temperature reading, helped, hindered, hypothesis (HHH), etc.
Intraspectives
The term, intraspective, consists of two words – intra meaning within (or insider) and perspective meaning the way of looking at things. Hence, intraspective is defined as an inspection or reflection for the team, within an iteration. Like a retrospective, an intraspective is a reflecting practice; however, unlike retrospective, it’s often preceded by an event that didn’t go well. Unlike the retrospective process, which can happen at points throughout the project, at the time of a release, or at the project level, the intraspective process happens within an iteration.
Let’s take an example with Scrum to understand. Post daily scrum, the Scrum Master noticed or heard something about consistent failure in release builds due to frequent configuration changes in the build scripts. The Scrum Master calls for an intraspective meeting on it to figure out if change is needed on the way team is modifying build scripts.
In iteration-based Agile methodology, the introspection meeting is, in essence, a retrospective within an iteration. The need for such can also occur in a flow-based Agile project. The purpose of an intraspective is to discuss a particular issue, event, or activity in order to determine if any change(s) are needed in the team’s practices.
The main goals of an intraspective is to inspect and adapt – the two key foundations of empiricism. Intraspectives happens on an ad-hoc or on-demand basis. It also helps in building a self-organizing team.
Key Points about Retrospectives
Irrespective of the type of retrospective or techniques used in a retrospective, below are a few key points to note while conducting one.
Item #1: Everyone should participate: If you remember the “setting the stage” step, we first discussed a check-in, which asked for everyone’s participation. When there is buy-in from the team as a whole, it is easier to proceed with further actions and improvements.
Item #2: Choose two techniques for each step (one short and one long). There can be many techniques or activities in the five steps of a retrospective. Preferably have one short and one long for each step, and you may altogether skip the shorter one, if you lack time.
Item #3: The Product Owner (PO) should be present: The PO is a core part of the team and should be present at retrospective meetings. As I interact with Agile practitioners, lack of the PO’s involvement has been noted by many as the most pressing issue. It’s important that the owner is a part of reflection discussions.
Item #4: For a longer retrospective, consider breaks. If the retrospective is more than two hours, ensure you have break on your agenda, even if it is just 10 minutes. Schedule breaks when there is a logical breaking point, when the energy level of the team drops, or when team members ask for one.
Item #5: Retrospective is not a post-mortem session. Any meeting that turns into dissecting issues or finger-pointing is futile. The retrospective should never be a whining session, rather an opportunity to contribute, reflect, and plan actions. Remember the story of the woodcutters and the retrospective prime directive, noted earlier.
--
This article was first published by MPUG.com on 15th October, 2019.
References
[1] I Want To Be An ACP – The Plain and Simple Way, by Satya Narayan Dash
[2] Agile Retrospectives – Making Good Teams Great by Esther Derby, Diana Larsen, and Ken Schwaber
[3] Agile Practice Guide, by Project Management Institute (PMI)
No comments:
Post a Comment
Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.