Why Is Retrospection Needed?
By Shreeti Bhattacharya
The dictionary meaning of Retrospective is “contemplation of the past events”, i.e. revise and analyse the past. Agile Retrospection is a ceremony performed at the end of every sprint to analyse, document and take actions to make the project and the process more transparent and productive. While Retrospection is very important to any project, it is also important to understand the boundaries created for the meeting team. While setting boundaries we should keep in mind that the freedom of speech of the team is not affected. To understand the concept of Retrospection Meetings better let me introduce you to the basics of the meeting first – <iframe width="560" height="315" src="https://www.youtube.com/embed/-hnD43Gs_ys" frameborder="0" allowfullscreen></iframe> The Correct Time – Last day of the sprint is the ideal day to hold the meeting The duration of the meeting – An ideal Retrospection Meeting should not be more than 20-25 minutes Required Members- Scrum Master, Product Owner, Developers The meeting generally starts with the common parameters of the team like velocity, user stories accomplished etc.Then each member of the team comes up with their opinions on – What went well? What went bad? What should the team continue doing? What should the team stop doing? Points given by each member is noted in a spreadsheet by the Scrum Master, and at the end of the meeting, 3-4 main action items are selected and are used as inputs to work on in further sprints. In every retrospective, the team should look back at the action items from the previous meetings and ensure that the ones that have been worked upon are closed. While in a new Agile team the members are hesitant to put forward their views openly, in an experienced Agile team it is easier to get the views easily and truly. Having covered all this it is important to understand that sometimes Retrospection meetings are used by employees to cover their mistakes or throw blames at other team members. For e.g. if the work of one developer is dependent on the work of another developer, there might occur a conflict of time or ideas between the two. Similarly, one developer's work might cause an issue in an existent piece of code written by someone else. These conflicts are often pointed at by developers during the retrospect and thus a healthy meeting turns into an introspection of each other’s work in the presence of the whole team and hampers the spirit of Agile. The team participating in the Agile Ceremonies should be trained and coached well to understand the practices advised in Agile and the reason behind them. Many Scrum Masters in today's day come across situations when differences occur between team members which are not good for the team to perform with complete dedication. In such situations, it is the duty of the Scrum Master to understand the differences and solve as quickly as possible to avoid internal conflicts which may eventually lead to bad team performance or delayed commitments. To avoid such introspection and team differences, the Scrum Master should make sure that the team adheres to the below guidelines – Always check with the teammates for any issues and try to solve in a mature and professional manner Resolve opinion differences regarding technical issues with logics and backing data Also, before starting every sprint it is very important to understand each requirement from business perspective to avoid confusion Also, it is a Scrum Master's duty to maintain a professional environment within the team and the Product Owner's duty to always clarify the business value of each backlog item so that the development team can follow the correct direction from sprint start. There are also some free tools available online like IdeaBoardz, Fun Retro, Reflect, Pointing Poker, Scatter Scope etc. Additionally, below-suggested guidelines for the meeting can help retrospect and come out to better conclusions as to what is best for the team : Each team member should contribute only 2-3 points most important according to their viewpoint When one team member is putting a point others should not contradict or speak in between Everyone should speak when asked to by Scrum Master If a conflict of opinion occurs between 2 team members then the same should be solved with only the concerned members and not to be put in retrospective When a team follows pure Agile, the Retrospective is an important ritual for the team. This helps Continuous Integration and helps the team understand each other’s point of view. A Retrospect could also be accompanied by the achievements of the team in the sprint. The Scrum Master can incorporate the team’s success in the start of the meeting to set a good tone for the meeting. Concluding, I can positively say that while good Retrospection can do wonders for the team, a bad one can break the team which is not good in the long run.
Shreeti Bhattacharya
Shreeti is a full time Scrum Master with Wipro and aspires to share her knowledge across.
Posts by Shreeti Bhattacharya
Why Is Retrospection Needed?
By Shreeti Bhattacharya
The dictionary meaning of Retrospective is “contemplation of the past events”, i.e. revise and analyse the past. Agile Retrospection is a ceremony performed at the end of every sprint to analyse, document and take actions to make the project and the process more transparent and productive. While Retrospection is very important to any project, it is also important to understand the boundaries created for the meeting team. While setting boundaries we should keep in mind that the freedom of speech of the team is not affected. To understand the concept of Retrospection Meetings better let me introduce you to the basics of the meeting first – The Correct Time – Last day of the sprint is the ideal day to hold the meeting The duration of the meeting – An ideal Retrospection Meeting should not be more than 20-25 minutes Required Members- Scrum Master, Product Owner, Developers The meeting generally starts with the common parameters of the team like velocity, user stories accomplished etc.Then each member of the team comes up with their opinions on – What went well? What went bad? What should the team continue doing? What should the team stop doing? Points given by each member is noted in a spreadsheet by the Scrum Master, and at the end of the meeting, 3-4 main action items are selected and are used as inputs to work on in further sprints. In every retrospective, the team should look back at the action items from the previous meetings and ensure that the ones that have been worked upon are closed. While in a new Agile team the members are hesitant to put forward their views openly, in an experienced Agile team it is easier to get the views easily and truly. Having covered all this it is important to understand that sometimes Retrospection meetings are used by employees to cover their mistakes or throw blames at other team members. For e.g. if the work of one developer is dependent on the work of another developer, there might occur a conflict of time or ideas between the two. Similarly, one developer's work might cause an issue in an existent piece of code written by someone else. These conflicts are often pointed at by developers during the retrospect and thus a healthy meeting turns into an introspection of each other’s work in the presence of the whole team and hampers the spirit of Agile. The team participating in the Agile Ceremonies should be trained and coached well to understand the practices advised in Agile and the reason behind them. Many Scrum Masters in today's day come across situations when differences occur between team members which are not good for the team to perform with complete dedication. In such situations, it is the duty of the Scrum Master to understand the differences and solve as quickly as possible to avoid internal conflicts which may eventually lead to bad team performance or delayed commitments. To avoid such introspection and team differences, the Scrum Master should make sure that the team adheres to the below guidelines – Always check with the teammates for any issues and try to solve in a mature and professional manner Resolve opinion differences regarding technical issues with logics and backing data Also, before starting every sprint it is very important to understand each requirement from business perspective to avoid confusion Also, it is a Scrum Master's duty to maintain a professional environment within the team and the Product Owner's duty to always clarify the business value of each backlog item so that the development team can follow the correct direction from sprint start. There are also some free tools available online like IdeaBoardz, Fun Retro, Reflect, Pointing Poker, Scatter Scope etc. Additionally, below-suggested guidelines for the meeting can help retrospect and come out to better conclusions as to what is best for the team : Each team member should contribute only 2-3 points most important according to their viewpoint When one team member is putting a point others should not contradict or speak in between Everyone should speak when asked to by Scrum Master If a conflict of opinion occurs between 2 team members then the same should be solved with only the concerned members and not to be put in retrospective When a team follows pure Agile, the Retrospective is an important ritual for the team. This helps Continuous Integration and helps the team understand each other’s point of view. A Retrospect could also be accompanied by the achievements of the team in the sprint. The Scrum Master can incorporate the team’s success in the start of the meeting to set a good tone for the meeting. Concluding, I can positively say that while good Retrospection can do wonders for the team, a bad one can break the team which is not good in the long run.
743
- by Shreeti Bhattacharya
- 17 Nov 2017
The dictionary meaning of Retrospective is “cont... Read More
Agile- Method or Mindset
By Shreeti Bhattacharya
The day I joined my first project as a Scrum Master, which I had to convert from Waterfall to Agile , I met my new team members who were more worried than relaxed, more perplexed than happy to become “Agile”. I got questions like “how do I manage my work”, “do I have to work more”, and soon realized I wasn’t only going to change the methodology for the project, I had a bigger task at hand, of changing people’s mindsets and making them Agile. I had to teach them not only how to implement Agile at their workplaces, but also how Agile can better their own lives. How planning,retrospection and a daily reminder to yourself that why are you here and what is the greater goal can make their lives and work easier and in line with the future goals. Those who have worked in Agile management can easily understand how the process is and how it helps the developers as well as the clients. Those who are new are often too scared to take it up as a challenge. They tend to believe that their freedom to take their own time to finish work will be lost, but they overlook the fact that they can actually portray their work more transparently and can play an important role in achieving business goals. Today’s clients don’t want to just hand in the requirements and then forget about it for the next 6months-2years time, and then get to see a completely mind boggling product in hand with a technology which will soon be outdated. In such cases, they will have to pay the company again to upgrade the product. Customers want to be updated with the progress of the product to cope up with the fast changing world. Being agile requires a lot of your focus and energy. Focus on the targets/commitments and energy to go with the velocity to achieve the target. This focus and energy cannot be taught in a training; it has to be instilled and has to be blended in the team to make them enthusiastic towards their work and understand Agile. A team may follow the process but the result may be zero if at the end of a sprint the team does not present the client what they had in mind. So it’s very important for every team member to know the business perspective of the client to deliver the perfect output. Agile processes demand transparency, commitment and output. Today the clients and end-users are also well informed; hence the producers of the product have to be all the more careful. When a team gets into a mode where they know the client’s goals and more importantly, align their goals to the client’s goals is when a team can be truly Agile. When we transform a team to Agile, we also must keep in mind that typically in a Waterfall model there are many roles and some of them are senior to others irrespective of the fact that they may be working equally. Agile promotes and stresses on a leaner model.So someone who may be a "lead" or "senior lead" will all be developers now. In many MNCs there are still so many hierarchies. Every hierarchy has its own mindset and to break that, is altogether a different challenge. In a very beautiful way Agile breaks all these boundaries and makes everyone work as one and credit everyone on achieving a "common goal". At the end of it all I can proudly say I converted a team's mindset to Agile and changed their way of thinking and enabled them to be the torchbearers for agile methods.
450
- by Shreeti Bhattacharya
- 24 Aug 2017
The day I joined my first project as a Scrum Maste... Read More