You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

Agile : Retrospective

Monday, September 28, 2015 | By
0.00 avg. rating (0% score) - 0 votes
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 optimised, 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.”
 
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 an iteration) 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. First we 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 (we call agile sprints as iteration here at Naukri).
 
Improved Productivity
We at one of our retrospective meetings found that while working on new stories there were some new errors/bugs encountered in other parts of the application. We found that we were spending a lot of time to solve them and hence the decreased throughput.
Then we decided to discuss the approach for all the stories in the pre-iteration meeting itself and identify the impacted areas so that we can keep those in mind while developing. We did this for subsequent iterations and we have improved on the rework and increased our productivity.
 
Improved Capability We recently implemented docker for easy and hassle free deployments in our organisation. Only one person knew in’s and out’s of the installation and its operation, creating a bottleneck for capabilities of the team.
 
So we decided to use the time we kept for knowledge transfer and technical trainings to learn docker and that team member helped us all. Now that bottleneck no longer exists, the team is not dependent any more and capability of the team has been improved significantly.
 
Improved Quality While working on stories for the given iteration, we observed that the requirements were not logged in time and there were changes in the requirements during the iteration as well. Also we identified that the summarized description of stories was creating confusion in minds of developers and quality analysts.
 
So we decided to groom out the stories in the previous iteration itself and applied a restriction on changes in the stories once committed for the iteration. This helped us freeze the requirements in detail and well before time.  Therefore the improved quality of delivery.
 
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.
 
So we decided to create more generalists over next iterations in our team.
(To know more about generalists and capacity planning visit http://engineering.naukri.com/2015/09/agile-capacity-planning/)
 
This helped us reassign the work to anyone in the agile team and hence improve the productivity and throughput of the team irrespective of unplanned decrease in capacity of the team.
 
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 do we start our 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 we did in the last iteration.
For example,
Team feedback :
  1. Despite the unplanned leave of two resources, we rebalanced 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.
 

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 misalignments 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, we 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, we use various reports for the given iteration that shows the pitfalls and the betterments very clearly.
 
Burndown Chart :
 
This shows the burndown of the committed story points. This should go linear with the line shown in grey color. This helps us identify the reasons for the burndown not being linear and we can improve that in upcoming iterations.
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.
 
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.
 
Build Quality Report :
 
We use 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 severities and priorities for the given iteration. We believe that 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.
 
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, we faced lesser productivity for the iteration because of delay by the external vendor (factor). So we 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)”.
 
  1. “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 :
 
 
Team doing their retrospective meeting :
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.
 
Stay tuned for more articles on agile !
All the best !!!
Posted in Agile, Software Development
Tags: ,