What are the benefits of Agile Retrospective meetings?
Thomas A. Edison said
“I have not failed. I’ve just found 10,000 ways that won’t work.”
So next time he tries to make a better version of bulb he knows the direction in which he does not have to go. Some notions or processes might seem sloppy, but actually provide value somewhere else in the company, or prevent other forms of scrap from being produced later. Other processes may seem valuable, but actually do not really result in any business value.
How often a software development time goes on producing nothing? How do you identify it? I am sure in most companies it is tough to spot what is scrap and what is not. We can take a cue from traditional manufacturing process and use it as an analogy to software development.
Toyota manufacturing system is a good example to learn general types of waste.
1. ‘Muda’ — Non-value adding actions within your processes;
2. ‘Mura’ — Unevenness or Inconsistency
3. ‘Muri’ — Overburden or be unreasonable
In doing this, they also identified types of waste in manufacturing, These are over production, excess inventory, waiting, Unnecessary transportation and defects.
In software development, it can be translated to more relevant terms:
1. Unnecessary or Partial features — Change in requirement causes certain piece of software become unusable. Sometimes unclear requirements results in partial features and mostly results in garbage.
2. Dependencies between features — New features are always built on top existing ones or considering integration with other features. Any delay in integration puts someone on waiting and adds to overall development time.
3. Multiple testing and review cycles — Each feature requires testing and review before going into production, if a testing & review cycle can combine multiple features, it can save huge amount of time.
4. Bugs/Defects — I guess it does not need any explanation
Thanks to agile development practices and ‘retrospectives’ in particular these wastes can be disposed off very easily. An agile retrospective, or sprint retrospective as Scrum calls it, is a practice used by teams to reflect on their way of working, and to continuously become better in what they do.
The Agile Retrospective
A retrospective is a meeting held by a software development team at the end of a project or process to discuss success and failure and future improvements after each iteration. You may never know what you learned today will be useful tomorrow. Steve Jobs called it as connecting the dots. Iterative learning and continuous improvement (kaizen) quickly helps to identify key issues and ways eliminating it. These retrospectives enable the team to make small improvements regularly, and apply them in controlled and immediate manner. The goal of retrospectives is helping teams to improve their working culture.
Inspect and Adapt — Twin motto of Retrospective
According to Ben Linders — “The whole team attends the retrospective meeting, where they inspect how the iteration (sprint) has been done, and decide what and how they want to adapt their processes to improve. The actions coming out of a retrospective are communicated and done in the next iteration. That makes retrospectives an effective way to do short cycled improvement.”
Above text is taken from blog What’s an Agile Retrospective and Why Would You Do It? written by Ben Linders
Typically a retrospective meeting starts by checking the status of the actions from the previous retrospective to see if they are finished, and to take action if they are not finished and still needed. The actions coming out of a retrospective are communicated and performed in the next iteration.
Scrum Master and his tools
Scrum Master is the retrospective facilitator who is accountable for understanding the roles of each member and remove difficulties to deliver the product goals successfully. The scrum master differs from the traditional project leader in terms of people management responsibilities. The Scrum Master is the enforcer of the rules of Scrum, chairs key meetings, and challenges the team to improve. Scrum master should have a toolbox of possible retrospective exercises and should be able to pick the most effective one given the situation at hand.
Above text is taken from blog What’s an Agile Retrospective and Why Would You Do It?
(You can also refer the book Getting Value out of Agile Retrospectives written by Ben Linders and Luis Gonçalves to learn more about such retrospective exercises)
Why would you do retrospectives?
It is insane to do same things and expecting different results. Problem solving approach and subsequently delivering more value to your customers, requires change in the way of working. That is why agile promotes the usage of retrospectives to help teams to solve problems and improve themselves.
Some more benefits of doing the Retrospective?
The most important benefit is that it cuts through hierarchy and gives equal power to the team members to open up and present their views effectively.
Retrospectives provide platform to celebrate success and ponder upon failures. Team members can deliberate upon the course of improvements to be included in the next sprint. Retrospective encourages participation, sharing of interests and views, taking the team towards an amicable solution. End of a retrospective let’s the team to start the next sprint with a clean slate.
In my opinion, process improvements should not be a separate process; instead it should be part of regular development process. If worked regularly, it can produce immediate results. It’s about establishing a culture across the company that strives to improve but does it with very small steps so assessment can be done easily.
Connect Deeper
If you resonated with this article, please subscribe to our newsletter. You will get a free copy of our Case Study on SMS-Bot Powered by Artificial Intelligence.
