Agile Retrospective: A Step-by-Step Guide to Continuous Improvement
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.
Hey there! This blog is almost about 1000+ words long & not everyone likes to read that much. We understand that.
This is precisely why we made a podcast on the topic. Mitul Makadia, CEO & Founder of Maruti Techlabs, talks to Bikshita Bhattacharyya about his Agile implementation, strategy, and process during the nascent stages of the company.
He walks us through the challenges he faced, how the business benefited from scaling Agile, and how important is the scrum master in making Agile a success at the organizational level. Here is a small snippet from that episode. Check it out!
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.
Do you wonder what one needs to avoid doing to become a good scrum master? Mitul Makadia does a deep dive on certain limits that every scrum master should take into account while leading his/her team on the path of a successful project.Take a look at the video below 👇
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 way of working.
Read also: The Ultimate Guide to Creating A Successful Agile Release Plan
Inspect and Adapt – Twin motto of Retrospective
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. 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 accountable for understanding the roles and responsibilities of the Agile development team. A Scrum Master is also responsible for removing difficulties in delivering the product goals and deliverables. 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. Some of the techniques to do retrospectives are asking questions, state your feelings with 1 word, 5 times why (Root Causes) or asking why, solution focused/strengths and retrospective of retrospectives.
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.
Did you find the video snippet on How to balance team efficiency with individual learnings in an agile environment? to be insightful? We have a ~22 min video where Mitul Makadia gets into the weeds, and we discuss about Implementing & Scaling Agile to streamline Software Development. Take a look –
What’s the benefit 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 effectively. Since the team members feel empowered, there will be little resistance to do the changes that need to be done.
Another benefit is that the actions that are agreed in a retrospective are done by the team members. The team analyses what happened, defines the actions, and team members do them. This creates a much faster, cheaper and effective process. These benefits make retrospectives a better way to do improvements. And they explain why retrospectives are one of the success factors for using scrum and getting benefits. You can use different retrospective techniques to get business value out of retrospectives. And retrospectives are also a great tool to establish and maintain stable teams, and help them to become agile and lean.
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.
