This famous quote by George Santayana is the basic philosophy behind Total Quality Management (TQM).  It seems like a pretty simple concept, to learn from your mistakes so that you don’t repeat them but the reality is that it is often very difficult to do. 

Even the steps are pretty simple:

  1. Identify and describe the problem or issue
  2. Determine the cause
  3. Resolve the problem
  4. Follow up and monitoring

So why is this so hard?  This is my take on what gets in our way:

“We don’t have time”

Software projects and releases are notorious for being time sensitive and often are behind schedule.  Teams are working overtime and often reacting to unexpected and unscheduled delays so the focus is often to just get it done.   When people are in a time crunch, this is when teams look for short cuts and want to deviate from the improved process to go back to their old ways.  It is difficult to stick to your guns and push for the new process.

Suggested Remedies

  1. Awareness – the team has to realize that although the short cut saves them time in the short-term, in the long run, it will always catch up with you.  It takes discipline to stay on the correct path, especially when it is something new and unproven.  It is human nature to stick to old habits.  Have past examples in mind when these discussions come up and remind the team why these changes were needed.
  2. Take Responsibility – it is incredibly frustrating for teams when they are pressured to find short cuts and then blamed when the short cut comes back to bite them.  Managers need to take responsiblity to either allow the team to take the extra time to do it right or take the responsibility of taking the short cut.  This builds trust within the team and keeps their faith with management.  It is impossible to work on continuous improvement if your team doesn’t trust you.
  3. Plan and schedule your improvements   The time to have improvement discussions is not in the middle of a high pressure release as you are not going to find a receptive audience.  The time to analyse and review past mistakes should never be when people are under pressure and stressed.   Designate someone to take action items when ideas are raised that can’t be implemented right away and host post-mortem reviews after the release is out the door.   Make sure that new changes to the methodology are factored into the next project schedule.  People need time to adjust to a new way of doing things.  Don’t overload team members with too many new changes all at once or there will be confusion and possibly a revolt!

“It wasn’t me!”

Lets face it, no one likes to realize that they made a mistake, let alone have the mistake aired publicly and dissected by the team.  The more pride a team member takes in their work, the more defensive they will be when problems are found.  You don’t want to discourage this sense of pride in their workmanship but you cannot allow people to get territorial and resistant to change.   I am Canadian and Canadians are notoriously polite and hate making a scene.  Team members are often reluctant to air problems for fear of being rude or impolite to a fellow team member.  We would rather smolder and steam than risk causing a scene but this means problems go unresolved and good team members get fed up and leave for better projects.

Suggested Remedies

  1. Set an example – if you are leading up the improvement process, find an example of something you might have done wrong and ask for suggestions for improvements.   Demonstrate that you don’t expect people to be perfect but you do expect a willingness to improve and grow but you must lead the way by your own actions.
  2. Avoid making it personal – try to keep the focus on what is best for the project and that the purpose is to find out what doesn’t work for the team, NOT to identify weak team members.  If a weak team member is a problem, this not the place for this discussion and the manager needs to take this offline as it distracts from the focus of improving the process.  Ensure that your language uses nouns of  the tasks and issues and not a person’s name – for example “the web API” rather than “John’s API”.
  3. Keep it light and find humor in the situation.  We once had an awards ceremony for the post-mortem review and the awards were home-made silly statues that gently poked fun at some of the hurdles that we had to overcome.  One developer got a stitched up rag doll as the “Patches Award” for the most number of hot fixes.  She wasn’t responsible for the number of hot fixes but she had to bear the brunt of managing all of them and it was a way of recognizing her hard work while at the same time recognizing that maybe we didn’t need so many!  Another team had a “Bad Ass Wizard” award for any developer that broke the automated nightly build.  If you came in to find the wizard on your desk, you knew you had work to do right away.  The wizard had to live on your desk until someone else broke the build.  No one wanted that ugly thing on their desk for long but it did make the rounds from time to time!

“It’s no use, we will never get better”

Sadly, there is a pessimist in every crowd and it can make the job of encouraging and promoting change extremely challenging.  They will point out every flaw and reason why it won’t work or it shouldn’t be considered while offering little as an alternative.  I have come to realize that there are people who actually enjoy working in chaos and feel that this gives them their stage to shine on.  For some, this is their job security because they have convinced the team that the project won’t survive without them to save the day when things get crazy.   Successful projects should never depend on heroics and sooner or later, people will be exhausted with the high stress stakes and you will lose your best people.  So how do you win over the doom and gloom crowd?

Suggested Remedies

  1. Allow everyone to contribute feedback and solutions.  So many times I have seen post-mortem reviews where only the management team attends.  It is the team members in the trenches that really know what happened day-to-day and often managers might have their own agenda to promote.  If you really want to know what happened with a project, don’t exclude the people who are directly impacted and  bore the brunt of the problems.  Allow them a chance to express themselves and offer ideas and you will find that the quality of the solutions improve and the team will adopt new changes more readily.
  2. Monitor the changes and provide metrics to the team.  Team members need to feel that they are making a difference.  Too often reports on the project status are circulated to upper management but the team also needs to see how they are doing.  They need to know if the improvement plans are working and what is still broken.  I had a Manager of Development who objected to my tracking the reopen rate of defects because he felt this looked badly for his team.   My argument was that a reopened defect was not necessarily a reflection of the development but a reflection of the project.  Defects could reopened because the requirement was not written properly and therefore not fully understood or that the original defect wasn’t properly documented by QA.  Regardless of the reason, it reflects churn in the project that could be eliminated or reduced.  By tracking these metrics and putting corrective action in place, the team could see if their efforts produced the results they were hoping for.  If improving the process requires more effort or work, people need to see that the results are worth the effort.
  3. Celebrate!  No one can stand a steady diet of issues and problems.   If we want teams to be open and honest about what isn’t working and where their problems are, we have to give equal time to what is working and celebrate our successes.  Team members that are excelling should be appreciated and recognized.   One company I worked for had a bank of Starbucks gift cards and team members could request one to send  thanks to team members who went the extra mile to help them out.   People are more open to change if they feel appreciated.