How to Manage the "7 Wastes" of Agile Software Development

Origins of the term waste

The concept of "waste" in business was coined in the manufacturing industry during late 1940s. It was used by Toyota. In those days, automobiles involved a huge amount of manufacturing, and companies had to charge their customers a high price. The only option for Toyota to reduce car prices was to find ways to reduce the manufacturing costs. As part of this exercise, they started identifying "waste," which meant the feature (or process step) that did not add value for the customer. Once they identified the waste, they created ways to eliminate that waste from the system.

Over time, "eliminate waste" became the fundamental concept of Lean, which was used in the manufacturing industry.

What is waste?
Waste is, in fact, the opposite of value (a capability delivered to the customer through which the customer attains a tangible or intangible benefit). So whatever feature or functionality or process step that neither adds value nor is used will be considered waste and should be eliminated from the system/product/process.

The seven wastes listed below were identified in manufacturing in the Toyota Production System (TPS) by Shigeo Shingo:

1. Inventory: Unfinished goods (also called as "work in progress," or WIP)
2. Overproduction: Producing more than the demand requires
3. Extra processing: Additional steps in the process that aren't really needed
4. Transportation: Shipping the goods from one place to the other
5. Waiting: Lag between process steps
6. Motion: Moving around within the process
7. Defects: Flaws in the deliverables that impact their features/functionality

Seven wastes of software development

Based on the seven wastes of manufacturing industry, Mary and Tom Poppendieck have defined seven wastes that are appropriate for software development. What follows provides information about the meaning of each of the seven wastes of software development, which can help us eliminate them (or at least reduce their impact) with respect to Agile software development. Generally, you will find these wastes during sprint planning or during sprint execution.

Waste #1: Partially done work

Meaning: It generally means that the work (story) that is not completely done as per your Definition of Done, and hence you cannot demo it or you cannot release it. This can include code that is not refactored, code that is not unit tested/integration tested, code that is not properly documented, code that is not deployable, etc.

Possible reasons:

1. Prioritizing a story without having complete information about that story from the product owner
2. Technical complexity that was not analyzed properly during the sprint planning
3. Wait time between the tasks that are identified to complete the story
4. Improper dependencies for this story based on other stories
5. Removing an existing story that is halfway done and getting a new story into the sprint
6. Incomplete/inadequate tasks identification

How can you eliminate it?

1. Try to have a detailed discussion with product owner to understand the functionality of the story, and also to understand what value it adds to the product. Then prioritize it for a sprint. This calls for great coordination and collaboration between the team and the product owner.
2. Try to evaluate the technical complexity of the story based on its functionality. If required, go for a technical spike before you arrive at the estimate. This will, at the least, help you assess how complex it is so that you can either pick it up directly or ask the product owner to split it -- or go with some other technical implementation approach.
3. Try to do tasks in parallel as much as possible. This should be the true Agile way and not a mini-Waterfall way. When you are stuck somewhere, look for help. Develop he cross-functional teams that can address this point effectively, because anyone can pick up any task at least to some extent.
4. Manage your product backlog in such a way that the dependencies among various stories are clearly identified before the stories are picked up for a sprint. Again, this needs lot of coordination and collaboration between the team and the product owner. Sometimes the product owner may not have understand the technical dependencies, so in such scenarios the team should help the product owner. Example: Log-in cannot be prioritized without registration.
5. When you have stories lined up (committed) for a sprint, do not try to manipulate them during the sprint. It will add unnecessary rework and will lead to a loss in velocity.
6. When you decompose the story into tasks in your sprint planning meeting, try to spend a good amount of time and involve all the team members. This will help you to come up with all the required tasks to complete the story. If you do not do this, you will have an insufficient list of tasks but, in reality, you will have to perform every task to complete a story. So the tasks that are not identified in your sprint planning may lead to additional effort that is not planned, so it may ultimately push your story to an "incomplete" state.

Waste #2: Extra features

Meaning: Providing more than what is being asked for. Remember the Pareto principle (80 percent of users use only 20 percent of the product features).

Possible reasons:

1. Lack of understanding of the product vision
2. Who is in your product's "target audience"?
3. Gold-plating by the development team
4. Wrong prioritization of product features

How can you eliminate it?

1. The product backlog is the baby of the product owner, who should map it to the product vision. He or she is also responsible for the product ROI. So the product owner is responsible for managing the product backlog according to the product vision. He should prioritize the stories as per the value.
2. Every product will have its own target audience, the primary users of the product. The product owner has to make sure to identify the target audience, and only then start creating the product backlog. If required, use personas to identify the features based on the target audience.
3. Gold-plating generally comes from the development team, and sometimes it can be unintentional. While prioritizing the stories for a sprint, the product owner and the development team have to come to a common agreement on the stories for that sprint, and they must stick to that list.
4. Right from the release planning, the product features have to be carefully prioritized. The keys to prioritizing these stories are value, cost, and risk.

Waste #3: Relearning

Meaning: Not using the knowledge that is available within the team members, trying to reinvent the wheel.

Possible reasons:

1. Lack of a proper knowledge-sharing process within the team
2. Lack of required documentation
3. Missing information radiation and osmatic communication
4. Distributed teams

How can you eliminate it?

1. The team should share knowledge continuously throughout the sprint. The best places for knowledge sharing are the daily Scrum meeting and the task board. All the team members should participate in all team meetings. This will enhance knowledge sharing.
2. The general myth about Agile is: "Agile is anti-documentation." This is not true. The team should prepare all the required documentation, but it should always be "just in time."
3. Try to keep all important information displayed in a team space so that everyone has equal access. Osmatic communication plays a vital role in information sharing and knowledge distribution. Make sure to document the "tacit knowledge" that will be repeatedly required. You can use tools such as SharePoint, Wiki, etc.
4. Co-location is the best approach for executing Agile projects. If this isn't possible, due to any practical reasons, use tools like videoconferencing so that knowledge sharing is easier.

Waste #4: Hand-offs

Meaning: Passing the work from person to another, after completing the first person's work.

Possible reasons:

1. The nature of the tasks required for a story
2. Teams working from different locations
3. Lack of visibility of the information

How can you eliminate it?

1. Sometimes it is unavoidable, and different tasks have to be done by different team members (e.g., analysis, UI, client-side coding, server-side coding, etc). It's good to have cross-functional teams so that, over a period of time, the handoffs can be reduced.
2. When teams are working from different locations (time zones), if the information is not properly handed over, then this will lead to waiting. So make sure there is a proper hand-off process, and obtain confirmation from the other side of the team. Also make sure to execute the tasks at one location as much as possible, as this will reduce hand-offs and waiting time.
3. Try to keep important flowcharts and wireframes visible and clear. This can also be helpful to reduce hand-off time. Your Kanban task board, with regular updates, will really help here, along with your Definition of Done.

Waste #5: Delays

Meaning: Anything that causes more time to deliver a value-added activity, or delays the beginning of the value-added activity.

Possible reasons:

1. Lack of required team members
2. Unwanted processes
3. Too many things in progress
4. External dependencies
5. Lack of "value" understanding
6. Assumptions/clarifications and impediments

How can you eliminate it?

1. Make sure you have all the required skill sets assigned to your project. If you start a sprint without having the required team members with the proper skill sets, this will lead to delays.
2. Identify only mandatory processes at the beginning of the sprint. For example, if you do not need to get the code review for all of the code, then categorize the code into low complex, medium complex, and high complex, and send only medium and high complex code for review. This will reduce the cycle time and increase efficiency.
3. Keep only what you can handle on your plate and leave the rest open. This will help other team members pick up the work that's based on their skill sets and bandwidth.
4. Make sure to have all required external assistance available in time for your work. For example, if you need an external architect review, plan for it up front. Similarly, if you're working with multiple teams from different locations, then encourage stub-based development. I have personally observed that when we have videoconferencing calls with other teams working from different locations, usually the videos won't work, you have to waste time to fix the problem, if it isn't fixed in a certain amount of time you need to make alternate arrangements, etc. (One way to tackle the delays in such calls is for the ScrumMasters from both teams go on the call two minutes beforehand and ensure that everything is working properly. Also, always keep a conference bridge number as backup, and after a fixed amount of time -- say, five minutes -- spent trying to fix any problems, move to the conference bridge.)
5. Always try to do value stream mapping and see what is value-added time and what is not. This will give you an idea of what your current process efficiency is. Based on the current state of the value stream map, and by applying Lean practices, you can improve the cycle time and thereby reduce delays. Also, automate the test cases wherever possible so that you can reduce a considerable amount of time when you have to run them recursively.
6. Make sure you get clarity on your assumptions and inputs for your clarifications at the right time. Raise the red flag before you get into the danger zone, and get proper attention from respective stakeholders. Track your impediments effectively; the ScrumMaster is responsible for resolving the team's impediments.

Waste #6: Task Switching

Meaning: Team members moving from one task to another without completing the first task properly.

Possible reasons:

1. Interruptions in the ongoing tasks
2. Lack of ground-level analysis of the tasks required for the stories
3. A shared team working on more than one project at a time
4. Lack of proper coordination between the product owner and development team

How can you eliminate it?

1. Interruptions can be due to many reasons, including lack of complete information about the task, hardware-related dependencies, etc. Make sure the tasks are detailed enough in the sprint planning meeting and identify any external dependencies up front. Raise them as impediments and let the ScrumMaster work on them.
2. Make sure to spend enough time when you're splitting the stories into tasks during your sprint planning meeting. You need to identify all the possible tasks, and also identify the order of those tasks, so that you can work on one story until it's completely done without any task switching.
3. Ideally, Scrum teams should be dedicated teams. If you have shared teams, then naturally that leads to task switching.
4. If the product owner does not provide the priority of the stories during the sprint planning, this may lead to juggling between stories during the sprint. This, in turn, leads to task switching. So try to have the stories prioritized by the product owner. For this the value, cost, and risk are the key factors, as mentioned above.

Waste #7: Defects

Meaning: Erroneous functionality that produces wrong output.

Possible reasons:

1. Lack of understanding on the story
2. The story does not satisfy the INVEST principle
3. Lack of engineering practices such as TDD, refactoring
4. Missing acceptance criteria
5. Lack of technical skill sets for team members
6. Late involvement of testers
7. Inattention to the automation testing

How can you eliminate it?

1. Don't jump in to story development until you have a complete understanding of the story. Refer to the tenth Agile principle -- simplicity, or maximizing the amount of work undone. Wherever more complexity is involved, then go with the "specification by example" approach.
2. The product owner has to ensure that the story follows the INVEST principle. If not, then try to split it into more granular stories.
3. Be strict about making test-driven development, pair programming, and refactoring part of your development plan. These are powerful engineering practices.
4. The product owner must attach the acceptance test criteria to each story that is prioritized for a sprint. This will help the developer understand the story in more detail from the implementation point of view.
5. Make sure you have right skills on the team and also have suitable coding standards and guidelines in place up front.
6. It is always good to have the testers involved right from the sprint planning stage. It will help them engage in the largest possible test coverage, which reduces defects.
7. Make sure to have an automated test suite created from the very first sprint. For any project, a certain number of test cases (sanity tests) will have to run more than once, so automating them will save time and also reduce defects.