Retrospectives: The Frustration

Most people these days are running in some sort of agile methodology where you have frequent planning sessions, releases and retrospectives. Personally, I quite like this methodology as it provides a tight feedback loop with the customer so that they can see the progress and change aspects of the application before it is to late in the process.

Frustration

However, when it came to retrospectives I often found them to be useless as typically all that would be discussed were the standard "What worked?" and "What didn't work?". However, when it came to the "What would we do differently?" question, this was either quickly glossed over or we would basically look at what didn't work and find ways to correct them and that is where it ended. There was no accountability for anyone to make sure that these things got corrected or the process improved. Essentially, we were doing it "cause the book said so"

What I found was that similar topics came up at each retrospective and time and time again nothing was done about it. Unfortunately, this showed in the poor quality of the product that was being developed. To add to this, tasks were often never completed and just kept on dragging over multiple sprints. We were also constantly fire fighting issues and for some reason the rest of the team seemed quite content about this as well, almost as if this was the norm.

Let's Do This!

When I started leading my own team, I tried some variations on how I thought a retrospective should be run, but in the end they didn't have the effect I was hoping for. For example, I tried to optimize them to make them quicker and to the point, as previously I found that people got bored and lost concentration. In addition, I often found it difficult to get input from the team members, which made the retrospective a bit pointless.

And so I began a journey of discovery on how to run an effective and useful retrospective.

What's The Purpose?

The point of a retrospective is to allow team members to directly influence the way they work. It allows the team to experiment with various options and ideas so that they can better achieve the desired results. In a way, this reminds me of the Japanese concept of Kaizen, which means "change for better", that was implemented by Toyota and allowed any employee in the company, from the CEO to the workers, to optimize the process in order to achieve a better end result.

NUMMI

However, just allowing the people in the organization to change the process is just one part of the equation. The other important part is company culture. You need to have a team, which includes managers and leaders, that are open to this way of thinking, else it will fail as was shown at the NUMMI plant. At this plant, Toyota showed General Motors all their secrets on how they achieve such a high standard of quality on their vehicles. Essentially, what Toyota was showing them was the process of continuous improvement and quality over quantity.

On the other hand, GM were focused on quantity over quality. Even when they were shown at NUMMI what they needed to do, many of the plant managers resisted it and made up excuses such as consumer reports on vehicle quality were biased towards Japanese cars. In some circumstances, managers never wanted to implement it as they were worried for their jobs and in other cases employees thought that this was a scheme to get rid of them, so they resisted the process.

GM also had the philosophy of never ever stop the production line, be it to fix an bolt that was loose or if someone was having a heart attack, no matter what the line was to never stop. If there were any issues with the vehicle once it was assembled it would be corrected at that point.
The reason for never allowing the line to be stopped is because the management at GM believed that employees would be doing this all the time, as the assumption was that they don't want to work. Essentially, there was no trust between the two parties and as a result, this lead to numerous problems and inefficiencies. For example, sometimes entire cars needed to be stripped to fix a part that could have been easily corrected at a much earlier point in time. There were numerous instances where customers received cars with a myriad of issues. This hurt their brand and caused a loss of trust in them, which once lost normally takes a lot of effort to win back.

Ironically, as Toyota became bigger and focused on growth, it became more like GM as it started to place greater emphasis on quantity which lead to numerous recalls & issues of their various vehicles.

I cannot help draw the parallels between General Motors and some of the software projects I have worked on. Managers are often to hasty to get the product out the door and fix any issues that come out afterwards. As a result, potential improvements to the software, or processes, are often put on the backlog only to grow stale and never see the day of light.

Listen

Any employee in an organization likes it when they are heard, or when you ask them for their ideas on how to solve a particular problem. The get a sense of feeling important and valued, at least in my experience. This creates a snowball effect which makes them continue to look for better ways and optimizations which at the end of the day creates a better product.

As a result of this, in the upcoming posts I will be going into how to run an effective and useful retrospective. I'm going to be learning along the way as well, so its going to be a fun journey.

Until next time...keep learning!