7 wastes of software development: Based on the 7 wastes of manufacturing industry, Mary and Tom Poppendieck have defined 7 wastes that are appropriate for software development. In this article we shall discuss the Origin of the concept of “Waste”, as developed in the Manufacturing industry, and the different types of Wastes in that industry. Later, we move to the Wastes in Software Development. We shall see the meaning of each of the 7 wastes of software development, the reasons behind them and, strategies to eliminate (or reduce its impact in case you cannot fully eliminate) with respect to the “Agile Software Development”.
“Waste” in the Manufacturing Industry
The concept of “Waste” had been initially coined in the manufacturing industry during late 1940s. It was used by “Toyota” cars manufacturing company. During those days, manufacturing automobile was a great deal which involved huge amount for manufacture it and subsequently they had to charge their customers with a high price to sell the cars. So the only option for Toyota to reduce the cars price was to find ways to reduce the manufacturing costs. As part of this exercise, they started identifying “waste” which means the feature (or process step) that does not add any value to the customer. Once they identify the waste, they created ways to eliminate that waste from the system.
Once they were able to identify the “waste” it was easy for them to come up with various ways to “eliminate” it from the system. Over a period of time, “Eliminate Waste” has become the fundamental concept of Lean which had been used in manufacturing industry.
What is Waste? Waste in fact is opposite to 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 any value nor being used, then it will be considered to be a waste and should be eliminated from the system/product/process.
Below 7 wastes were identified in manufacturing industry in Toyota Production System (TPS) by Shigeo Shingo:
- Inventory: Unfinished goods (also called as “Work In Progress” WIP)
- Overproduction: Producing more than the demand
- Extra processing: Additional steps in the process that are not really needed
- Transportation: Shipping the goods from one place to the other
- Waiting: Lag between process steps
- Motion: Moving around within the process
- Defects: Flaws in the deliverables that impact the feature/functionality
7 Wastes of Software Development
Based on the 7 wastes of manufacturing industry, Mary and Tom Poppendieck have defined 7 wastes that are appropriate for software development. They are:
- Partially Done Work – It generally means that the work (story) that is not completely done as per your “Definition of Done”.
- Extra Features – Providing more than what is being asked for.
- Re-Learning – Not using the knowledge that is available within the team members and trying to reinvent the wheel.
- Handoffs – Passing the work from one hand to the other after completing the first person’s work.
- Delays – Anything that causes to take more time to deliver a value added activity or delay the beginning of the activity that adds value.
- Task Switching – Team members moving from one task to another without completing the first task properly.
- Defects – Erroneous functionality that produces wrong output which is not matching with the desired output.
We shall see the meaning of each of the 7 wastes of software development, reasons behind, and possible strategies to eliminate (or reduce its impact in case you cannot fully eliminate) with respect to the “Agile Software Development”. Generally, you will get into these wastes during your sprint planning or during your sprint execution.
Waste #1: Partially Done work
Meaning of Partially Done Work: 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 for Partially Done Work: There could be many reasons to have partially done work and some of them are given below.
- By prioritizing a story without having complete information about the story from the product owner
- Technical complexity that was not analyzed properly during the sprint planning
- Due to the wait time between the tasks that are identified to complete the story
- Due to improper dependencies for this story with other stories
- By removing an existing story that is halfway done and getting a new story into the sprint
- Incomplete/inadequate tasks identification
How can you eliminate Partially Done Work?
- Try to have detailed discussion with product owner and understand the functionality of the story and also understand what “value” it adds to the product. Then only prioritize it for a sprint. This needs great coordination and collaboration between the team and the product owner.
- Try to evaluate the technical complexity of the story based on the functionality. If required, go for a technical spyke before you arrive at the estimate. This will at least help you to assess how complex it is so that you can either pick it up directly, or you can ask the product owner to split it or to go with some other technical implementation approach.
- Try to do tasks in parallel as much as possible. This should be really Agile way and not a mini waterfall way. When you stuck somewhere, look for help. Develop the cross functional teams which will address this point very effectively, because anyone can pick up any task at least to some extent.
- 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 idea on the “technical dependencies” so in such scenarios the team should help the product owner. Example: Login cannot be prioritized without registration.
- 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 gets down the velocity.
- When you decompose the story into tasks in your sprint planning meeting, try to spend 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 insufficient list of tasks but in reality you have to perform “all” tasks to complete a story. So the tasks that are not identified in your sprint planning may lead to additional effort which is not planned so it may finally push your story to “incomplete” state.
Waste #2: Extra Features
Meaning of Extra Features: Providing more than what is being asked for. Remember the Pareto rule (80% of the users use only 20% of the product features).
Possible reasons for Extra Features: Again, this will happen due to many reasons as given below.
- Lack of understanding on the product “VISION”
- Who are your product’s “Target Audience”?
- “Gold plating” by the development team
- Wrong Product features prioritization
How can you eliminate Extra Features?
- The product backlog is the baby of the Product Owner who should map it to the product vision. He is also responsible for the product ROI. So the product owner is responsible to manage the product backlog according to the product vision and manage it accordingly. He should prioritize the stories as per the “Value”
- Every product will have its own target audience who are the primary users of the product. The product owner has to make sure to identify the target audience and then only start creating the product backlog. If required, use personas to identify the features based on the target audience.
- Gold plating generally comes from the development team and this can be sometimes unintentional too. 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.
- Right from the release planning, the product features have to be carefully prioritized. The key to prioritize these stories are “Value, Cost & Risk”.
Waste #3: Relearning
Meaning of Relearning: Not using the knowledge that is available within the team members and trying to reinvent the wheel.
Possible reasons for Relearning: Below are some of the potential reasons for this waste.
- Lack of proper knowledge sharing process within the team
- Lack of required documentation
- Missing information radiation and osmatic communication
- Distributed teams
How can you eliminate Relearning?
- Team should share their knowledge continuously throughout the sprint. The best place for knowledge sharing is the daily Standup Scrum meeting and the task board. All the team members should participate in all team meetings. This will enhance the knowledge sharing among the team.
- General myth about Agile is “Agile is anti-documentation” but this is not true. Team should prepare all the required documentation but it should always be “Just In time” (JIT)
- Try to keep all important information displayed at team space so that everyone would have 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.,
- Co-location is the best approach to execute Agile projects. If this is not possible due to any practical reasons, use tools like Video conference so that it will be useful for knowledge sharing.
Waste #4: Handoffs
Meaning of Handoffs: Passing the work from one hand to the other after completing the first person’s work.
Possible reasons for Handoffs: Below are some of the potential reasons for Hands off.
- The nature of the tasks required for a story
- Teams working from different locations
- Lack of visibility of the information
How can you eliminate Handoffs?
- Sometimes it is unavoidable and different tasks have to be done by different team members (Eg: Analysis, UI, Client side coding, server side coding etc). It is good to have cross functional teams so that over a period of time, the hand offs can be reduced
- When teams working from different locations (time zones) if the information is not properly handed over, then this will lead to wait time. So make sure there is proper handover and obtain confirmation from the other side of the team. Also make sure to execute the tasks at one location as much as possible this will reduce the hand off time to the possible extent.
- Try to keep important flow charts and wireframes visible and clear. This can be helpful to reduce the hand off time. Your Kanban task board with regular update will really help here along with your “Definition of Done”
Waste #5: Delays
Meaning of Delays: Anything that causes to take more time to deliver a value added activity or delay the beginning of the activity that adds value.
Possible reasons for Delays: Following are some of the reasons for Delays.
- Lack of required team members
- Unwanted processes
- Too many things in progress
- External dependencies
- Lack of “Value” understanding
- Assumptions/clarifications and impediments
How can you eliminate Delays?
- Make sure you have all the required skillset assigned to your project. If you start a sprint without having the required team members with proper skill set it will lead to delays.
- Identify only mandatory processes at the beginning of the sprint. For example if you do not need to get the code review for all 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 the process efficiency
- Keep only how much you can eat, in your plate and leave the remaining open. This will help the other team members to pick the work based on their skill set and bandwidth.
- Make sure to have all required external assistance available on time for your work. For example if you need an external architect review, plan for it upfront. Similarly if you are working with multiple teams from different locations, then encourage to use “Stub based development”. I personally observed when we have VC calls with other teams working from different location, usually VC will not work, you have to waste some time to fix the issue, if it is not fixed in a certain amount time then again you need to make alternate arrangement etc.
One way to tackle the delays in VC calls, the Scrum masters from both teams go to the VC call 2 minutes before and ensure the VC is working fine. Also keep a conference bridge number as backup always and after a fixed time duration (say 5 minutes) spending on VC and if it is not working then move to conference bridge.
- Always try to do “Value Stream Mapping” and see what is the value add time and what is non-value add time. This will give you an idea of what is your current process efficiency. Based on the current state of value stream map and by applying lean practices you can improve the cycle time and thereby reduce the delays. Also automate the test cases wherever possible so that it will reduce considerable amount of time when you have to run them recursively.
- Make sure you get clarity on your assumptions and inputs for your clarifications in the right time. Raise red flag before you get into danger zone and get proper attention from respective stakeholders. Track your impediments effectively; Scrum Master is responsible to resolve all the team’s impediments.
Waste #6: Task Switching
Meaning of Task Switching: Team members moving from one task to another without completing the first task properly.
Possible reasons for Task Switching: Following are some of the reasons for Task Switching.
- Interruptions on the ongoing tasks
- Lack of ground level analysis on the tasks required for the stories
- Shared team working on more than one project at a time
- Lack of proper coordination between product owner and development team
How can you eliminate Task Switching?
- Interruptions could be due to many reasons such as lack of complete information on the task, hardware related dependencies etc. Make sure the tasks are detailed enough in the sprint planning meeting and identify any external dependencies upfront and raise them as impediments and let the scrum master work on them.
- Make sure to spend enough time while you split the stories into the tasks during your sprint planning meeting part 2. 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 is completely done without any task switching
- Ideally scrum teams should be “dedicated” teams. If you have shared teams then naturally it leads to task switching
- If product owner does not provide priority of the stories during the sprint planning, it may lead to juggle between stories during the sprint which in turn lead to task switching. So try to have the stories prioritized by product owner. For this the “Value, Cost and Risk” are the key factors as mentioned above.
Waste #7: Defects
Meaning of Defects: Erroneous functionality that produces wrong output which is not matching with the desired output.
Possible reasons for Defects: There can be numerous reasons for defects; some of them are listed below.
- Lack of understanding on the story
- Story does not satisfy “INVEST” principle
- Lack of engineering practices such as TDD, Refactoring
- Missing acceptance criteria
- Lack of technical skillset for the team members
- Late involvement of testers
- Inattention to the automation testing
How can you eliminate Defects?
- Do not jump in to the story development until you have complete understanding of the story. Refer to the 10th agile principle “Simplicity – maximizing the amount of work undone”. Wherever more complexity involved then go with “Specification by Example” approach.
- Product owner has to ensure the story should follow INVEST principle. If not, then try to split into more granular stories
- Strictly make Test Driven Development, Pair Programming and Refactoring as part of your development plan. These are very powerful engineering practices
- Product owner must attach the acceptance test criteria for each story that is prioritized for a sprint. This will help the developer understand the story more in detail from the implementation point of view
- Make sure you have right skilled on the team and also have the suitable coding standards and guidelines in place upfront
- It is always good to have the testers involved right from the sprint planning stage. It will help them to cover largest possible test coverage which reduces the defects
- Make sure to have automated test suite created from sprint #1 itself. For any project a certain number of test cases (sanity tests) will have to run more than once, so making them automated will save time and also reduce the defects