Running an agile team, Iterate better with quality retrospectives.

Retrospective : (Dictionary meaning) the action of looking back on or reviewing past events or situations, especially those in one’s own life.

Let us start with a very simple example. Say someone is trying to lose weight for last 6 months and nothing works out for her. Then her friend suggests that running 3 miles/day for a month will do the trick.

So she started running as suggested. Now should she keep on running for months or observe the results for the activity for last one month?

If your answer lies in second half of the question

Welcome to agile Retrospective.

In every walk of life, we always like the optimized, flexible and easy path to solve problems. When we choose any approach, we follow that for stipulated amount of time and then we analyze. After each and every process in life, analyzing is important. It leads to the feedback of the entire process, team, tasks we did and many more.

Results always help us improve, no matter they are good or bad we always learn from them.

Retrospectives can make your organization faster, more efficient and innovative.” … Ben Linders

Talking in terms of Agile retrospective meetings.

Wikipedia says that

Retrospective is a meeting held by a project team at the end of a project or process (often after aniteration) to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects.

Improvements in agile methodology can be countless and worthy. At first I would like you to take through some examples so that you can relate it to your working environment and understand the blog post better.

Some of the viewpoints/examples are listed below where teams identified improvements in various parameters and applied new improved practices in the next iteration.

Some day to day Examples of improvement

Improved Productivity

Say you found that while working on new stories there were some new errors/bugs encountered in other parts of the application and hence deduce a lot of time to solve them and hence the throughput is decreased.

Solution ?

Well this at least highlighted an issue in front. You can often plan for such issues in advance. In due course the team will get mature enough to handle such issues.

Improved Capability Suppose you recently implemented a latest technology in your system as a Proof of concept. Only one person knew in’s and out’s of the installation and its operation, creating a bottleneck for capabilities of the team.

Solution ?

So you can cater this highlighted issue after each successive sprint and say provide technical training to the other team members to improve overall capability. Now that bottleneck no longer exists, the team is not dependent on one person any more and capability of the team has been improved significantly.

Improved Quality Your team knows the quality of the release by itself. You can often identify the reasons behind the same and improve the quality for the next time.

Increased Capacity We can never be sure about the uncertainties like unplanned leaves, unplanned office events etc. This factor does exists but you can not plan for that already.

Decide to create more generalists over next iterations in our team.

Know more about generalists and capacity planning.

Along with bottom line benefits, retrospectives have a way of increasing teamwork, empowerment and enjoyment for teams. When everyone is free to express their feedback for the entire iteration they feel empowered and involved in the team.

How to start your retrospective meetings?

Question 1: What Went Well?

When you are positive you can give better inputs and keep the team happy as well. So we start with the positive question to get everyone on board.

In this phase, team shares the feedback for every good thing it did in the last iteration.

For example,

Team feedback :

  1. Despite the unplanned leave of two resources, the team re-balanced the work among remaining generalist members and were able to finish all stories well in time. This shows that the complete team is almost equally capable and believes in teamwork.
  2. Handled security loopholes identified by the team in the iteration itself.

You may come across the similar examples when discussing the good part of your iteration.

Question 2: What Didn’t Go So Well?

The answers we get from this one, are very valuable for the team and their productivity. This highlights the difficulties, issues, problems etc faced by the scrum team.

Working as a team is not an easy task, there are too many moving parts and there is bound to be friction and misalignment.

But it is important to identify misalignment and keep on doing realignments and optimizations. In case there are no issues identified then probably we are doing something wrong or not participating in the retrospective meeting completely.

For example,

Team Feedback : In one of the stories, The product required integration with payment gateway which took long to register as merchant and hence delay in getting the exposed payment API to implement. This particular story was dependent on the external vendor, it was bit unexpected but realistic.

To visualize this question and context better, There are various reports available for the given iteration that shows the pitfalls and the betterment very clearly.

Burn down Chart :

This shows the burn down of the committed story points. This should go linear with the line shown in blue color. This helps us identify the reasons for the burn down not being linear and we can improve that in upcoming iterations.

Image Source : https://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png

Velocity Report :

This shows the velocity of the team, the points we committed and the points we delivered. This also shows consistency of the team and the average story points the team can deliver.

Image source : https://confluence.atlassian.com/agile/files/391087316/gh_6-2-1_velocity-chart.png

Control Chart :

Below is the control chart that defines the control over the past iterations (i.e over the product). This helps to predict whether the team will be able to deliver the product well in time or not.

Image Source : http://steveakers.com/wp-content/uploads/2013/03/sample-control-chart.png

Build Quality Report :

We can build quality report to ascertain the quality of our builds during development. This report is generated after considering all the functional, UI, implicit requirements bugs along with their severity and priorities for the given iteration.

If we build things better in the initial go then we will be faster and more efficient in the longer run. Thus tracking build quality during development helps us track and identify our strengths and weakness, so that we can work on improving them.

Image Source : https://i-technet.sec.s-msft.com/dynimg/IC343192.png

The above question puts us in the right mindset where we have identified a set of problems we faced and the whole team feels the necessity of the solution for the same. So now comes the later part of the question

“How could we improve that?”

Here the team provides the solutions for all the pitfalls and we implement them in subsequent iterations.

For example, as the problem stated above, the team faced lesser productivity for the iteration because of delay by the external vendor (factor). So the team decided to discuss stories 2–3 iterations before actually developing them. This provided the necessary time to deal with external factors and hence removed the dependency.

Question 3: What Have I Learnt?

This question is for individual team mates giving their inputs to what they tried new, learned something, observed some valuable thing that can be helpful for other team members as well. Some examples might be like mentioned below :

  1. “I’ve learned that getting your work reviewed from someone other than your teammate can help you get insights of the things which you might not get in your team (as you already know the inputs you are going to get)”.
  2. “Digging more into the code you write gives you better understanding of the nuts and bolts behind the scenes rather than just writing piece of code to see a functionality working in front of you.”

These improvements are not necessarily limited to the kind of work you do. These can also be for the organisational processes that will benefit the team/iteration throughput.

Embed your Learning in the Team

The team is a single unit and hence it delivers. The team is responsible for every good or bad and has the ownership of the domain they are working in. Therefore it is important to share and implement the learning in the whole team.

Some snapshots from our retrospective meetings

Answers to the three questions :

Summary

Finally Agile is equivalent to teamwork and everything we do is for betterment of the team.

If the team gets capable, determined and responsible, it will lead to improved productivity for the team and organisation.

Our main task is to get answers for all the questions we listed above and inject the leanings into the team.

Participation is very important. Though it is the team who manages the whole iteration but it’s the key responsibility of the facilitator/scrum master to conduct and guide the retrospective meeting on right track in order to derive qualitative outcome.

The quality inputs from the team helps the productivity very much and brings ownership as well.

Be a better team always.

If you are a better team, you will understand and implement every element of agile very easily. Be a single team unit, Keep doing quality work, keep retrospecting and keep improving.

Improvement and adaptability are the most important motives of agile methodology.

“I am writing it to help you out, you should recommend it to helps other out”

Hit the subscribe button for more such articles and give your feedback below.

Keep smiling and keep growing.

All the best !!!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.