join DYT Insider
Discover Your Creative "Super Powers"
100% Privacy. Zero-Spam.
Agile Retrospectives is an interesting and important topic that finds its way into a conversation in any Agile or Product conference or meetup. For a long time, every time I came across a question on Agile Retrospectives, I pointed people to Esther Derby and Diana Larsen’s excellent Google TechTalk. This is the best resource for Agile Retrospectives I have ever come across – please bookmark the link, if you haven’t seen the video yet.
But there was a problem in using this while coaching new teams that aren’t really self-driven. About four years back, I was presented with a situation…a company where 6 engineering teams were trying to adapt Scrum development practices. Each team had roughly about 6 members each and were attempting iterative development practices with 3 week iterations. They were struggling to ship software every 8 months (sometimes it took 10 months!). They wanted to establish a release cadence of 6 months.
The company had a lot of managers and directors. Every one in the team had an opinion on why they were struggling to ship software regularly. There was a feeling of lack of trust between the teams and the management. The need was a deep retrospection of the state of the product. More importantly, the need was to end with an outcome thats actionable and measurable. The approaches that I took were a combination of the Agile Retrospectives, as described by Esther and Diana in the above video, and a set of systems thinking and problem solving tools. Sounds good? Let’s plunge into this right away!
Let me give you a quick dope of the flow of the different set of activities, before we actually dived deep into each of them. Here is how the 6-step flow looked:
Let’s now get into the details of each of the above steps in the flow. Get ready for some fun!
Agile retrospectives are best done by teams themselves, without the participation of managers or just about anyone that can dissuade teams from having an open and candid chat. As someone new to the company and as someone leading a process transformation, I was privy to all the conversations – and the teams were perfectly fine with me being amongst them. Each team retrospected for over 1-2 hours each (this was the first time they did a retrospective…took some time!). Here is what the flow of each team’s retrospective looked like:
Every team member, be it a developer or a quality analyst, had an opinion on what change they wanted to see happen as a result of this exercise. Every team took a few minutes to come up with a set of 3-5 goals that they wanted to work towards and make happen. They had post-it stickies, walls and pens at their disposal. It was an interesting exercise. Some of these goals were a little abstract in the way they were captured, but that was OK as the team had a shared understanding of the goals as they discussed them. Below is a snippet of the goals of one of the teams. This exercise took relatively a shorter amount of time, except for the initial time I took to set the direction and goals of this exercise.
Once a team set its goals, it was time to shift to a totally free-flow activity of gathering data. There are a lot of techniques discussed in the Agile Retrospectives book by Esther and Diana. Some methods worked for some teams while the others found something else more interesting. But since this was the first time the teams were retrospecting, I found the Timeline pretty useful as it made them drift through time and pick their brains.
Teams put down what they thought worked and what they believed didn’t work in post-it notes and they were all over the wall. Some stickies generated more discussion and they resulted in addition of more stickies and sometimes deletion of them. This was mostly a silent exercise, except towards the end, when team members got into a discussion. But then I realized it was time to get into some analysis.
Now that the team was done pouring their hearts and minds out, it was time to generate some insights. The teams were already brainstorming as soon as they were done with brain-dumping. The teams now started to use tools like Five Whys, Patterns and Shifts, Cause-Effect analysis (remember the Fishbone diagram?) and identified themes.
Finally the teams wound up the retrospectives with a bunch of appreciations for fellow team members, people across teams thanking each other. Teams also identified some areas of improvement, and if they were significant and common across teams, it was captured as a measurable goal.
At this point we had clear idea of goals that each team intended to go after. Teams also had the opportunity to understand some underlying challenges. The next step was to make the retrospective actionable. How can the goals be tracked and measured? Which goals do we start to focus on first? It’s insane to focus on all these goals in a random way. Nothing would get done.
Once all the teams were done with their retrospectives, we took the goals from across the teams and spotted many overlapping goals. If multiple teams wanted to achieve a certain goal, it was given a higher weightage. For instance, if three teams had the same goal, the goal will have a weightage of 3. This way, we unified the goals along with the weightage for each. They were ranked in defending order of weightage. Figure below shows the ranked goals to be measured.
It’s great to rank goals and give them weightage. It gives us great clarity on how teams share common goals. Now it was important to understand how to go about achieving these goals. These goals were not independent of each other. For example, some team wanted “completeness of user stories” and some other wanted “release and iteration estimation to get better”. Now the latter wouldn’t happen if the former was not addressed.
At this point we brought together two members of each team and created something I call a Goal-Impact cascade. Essentially what this diagram tried to accomplish was to understand how each goal impacted the other. What is the cost of not achieving a goal? Below figure shows the Goal-Impact cascade.
At this point there was immense clarity on how these goals played out against each other. It was now important to establish shared ownership. We brought in all teams, along with the managers (as some of these goals needed managers to take action). We presented everyone the Goal-Impact cascade and explained the rationale behind the exercise. There was total agreement. I facilitated a discussion amongst everyone about the shared ownership, and we identified who needed to do something for each of those goals to be met. We also documented what they needed to do, if there was clarity, in order to achieve a particular goal. Below figure shows the Goal-Impact cascade with the ownerships.
Change cannot happen if it cannot be measured. This was the last step in the process where we established measurements to measure each goal. For each goal, we identified three measurement yardsticks:
Goals needed these three measurement yardsticks because it’s wrong to assume that goals will only be measured when they are achieved. This was a useful exercise as it led to significant results.
This Agile Retrospectives exercise led to actionable metrics that in turn led to the teams achieving more than 70% of the goals. The goals that were not very successful was indeed the usual suspects like better estimation and completeness of user stories. But even they improved over a period in time, but the teams found it hard as they came from the waterfall development world and were used to detailed PRD-like requirements.
I hope you find this approach helpful. This was an experiment that yielded satisfactory results, and I urge you to try this out and improvise on this. This works great in cases where you are undertaking a transformation initiative in any company that may or may not be following Agile development practices. This has nothing to do with Agile development practices, except for borrowing the Agile Retrospectives approach. Good luck with your next retrospective!
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.