How to Use Retrospectives to Eliminate Waste?

In Agile, there are many uses of retrospective meetings.  They put a check to make sure that the process is helping the team rather than hampering their progress.  One of the benefit is to identify and eliminate the different forms of waste that the project may give rise to.  Let us talk about them in this post.

A waste is something produced by the project involving money and time that delivers no tangible business value.

Greatly inspired by the lean manufacturing principle, Mary and Tom Poppendieck identifies the following forms of waste that the software projects may generate.  Retrospective meetings can be used to indicate the presence of such waste in a project and find ways to eliminate them.

Here are the questions you can ask the project team…

#1 What is the volume of Partially Done Work at any given time?

It refers to any work that is done partially but cannot be completed due to dependencies.  Here are a few examples:

• Functional specifications waiting for approval
• Code that is developed but waiting to be tested
• Specs that are created but waiting to be developed

Higher the number of partially done work, lower is the value delivery from the Project to Business.  The goal of the process improvement in this case, is to minimize the amount of partial work at any given time.

#2 Are there Extra Processes that don’t add value?

Next good question to ask your team is about the extra process in the system that don’t add value.  Value Stream Mapping is a good technique to identify such non-value adding processes.  Here are the steps involved:

The goal is to minimize the number of non-value adding steps to improve the process efficiency.

#3 Are there Extra Features built into the product that are not required?

It is normal that the team is developing extra features the business will never use.  By asking right questions, retrospective meeting can help to improve the process to prevent such wastage.

One efficient strategy is to improve the quality of “Done Criteria”.

Done criteria describe the qualities or attributes a finished product must possess to be considered complete and usable by the business.

By reviewing and refining it many times with the business, the team can eliminate features that are ‘nice to have’ but not required by the business.

#4 Do the team members switch frequently between Tasks?

Regular multi-tasking is a hindrance to productivity.  It may also lead to increased waste because the team member must switch to something else before finishing the original task.

Kanban suggest a good way to minimize multi-tasking by limiting the WIP (Work in Progress).  

For example, limiting a team member to work on a maximum of 2 work items at any given point in time can minimize the time spent in switching.

A word of caution, if the team is constantly swapping the WIP items with the To-Do list, no benefits are realized.  A Scrum Master must identify such trends and look for improvement.

#5 Is the team Waiting a lot?

Waiting long for something or someone in a software project is a serious form of waste.

Value stream mapping technique that we discussed earlier can be used to identify bottleneck activities that cause an increased waiting time.

A Cumulative Flow Diagram (CFD) that include the Burn up chart and WIP is another tool to identify the bottleneck process or activity causing the delay.

In the above diagram, the Analysis activity seems to have a widening band indicating lot of waiting time or bottleneck.  This suggest that the activity before it – DB Procs – may potentially be the bottleneck activity.

#6 How much time the team is spending in Motion?

This is a common form of waste in teams that are not co-located.  A lot of time is spent in communication across sites.  Also time and effort is wasted to transfer information or work by the way of knowledge sharing discussions.

These are acceptable as one time activities but a regular delay can cause some serious waste from the project.  Ask the team for right solutions to minimize this form of waste and improve value delivery from the project.

#7 Are there too many Defects?

Last but not the least are Defects.  This refer to all form of defects arising from incomplete or ambiguous requirements, incorrect specifications, not-so-good software development practices and lack of testing.

Following are the detrimental effects of too many defects in a project:

• It takes a complete cycle of requirement analysis/clarification, development and testing to fix a defect, thus costing a lot of additional time
• Escaped defects (found by customer) cause serious damage to the reputation and potential loss of business money
• A lot of administration time is spent in managing the defects and making sure they are fixed on time
• Decreased morale in the team due to presence of huge number of defects
• Perceived lack of quality by top management due to the high volume of defects

Get suggestions from the team to minimize defects and fix them early in the project life cycle.  Here are the steps in incremental test strategy that can find defects as soon as they occur!

• Pair programming
• Code reviews
• Unit testing
• Integration testing
• System testing
• Acceptance testing

To Summarize

Retrospective is an important meeting in Agile teams and it can help to identify and minimize waste that the project is producing.  Here are the questions that can help identify waste in a software project.

What are your strategies to minimize waste in your project?  We would love to hear your thoughts.