In the 1930s, the Toyota Production System gave us . Now, the IT, software and web development industry have also adopted these principles to improve their production processes. In actuality, the concepts and principles of Lean are used in more ways than just in manufacturing. Yet, in IT and software, there are still those who are pointing towards Agile development when they mention Lean and software development in the same context. While it is true that Agile and Lean principles share similar philosophies, there are key differences which set them apart. Diving deep inside Lean, I will discuss what lean talks about other than it’s key points. lean manufacturing principles A Brief Look At Agile And Lean Software Development ’s primary concern is to raise adaptability. The speaks in detail about individual interactions, small incremental releases and customer collaborations. It emphasizes the quick response to changes and requirements. This way, the software development teams can quickly adapt to updates and start pushing those changes consistently and frequently. As an example, the following are the Agile values according to the manifesto: Agile development Agile Manifesto Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change than following a plan. , on the other hand, highlights actions that don’t bring improvement to the final product or the process as a whole. It speaks about Wastes in Software Development present in seven ways. These are as follows: Lean development Inventory Overproduction Extra-Processing Transportation Waiting Motion Defects All credits to and their book, . The world of software development and web design now knows the significance of analysing every process for efficiency. Mary and Tom Poppendieck Lean Software Development: An Agile Toolkit Why Move To Lean Software Development? Let’s take a look at by the ’s Department of Business Administration. They report that about under study saw improvement in product quality by adopting a lean system. One example is the in Oregon, which back in 2002 after adopting a lean model. research Turiba University 73% of companies Timberline Software also reported improvement in quality Perhaps might sweep all arguments. Under their several improvements, they experienced a and saw a . Impressively, their improvement in software . In short, their mean number of bugs declined and the number of . BBC Worldwide 47% less variance 37% increase in software delivery delivery speed did not affect their product quality defects fell by 24% At the end of their study, the university affirms the experiences of BBC Worldwide and other companies who turned towards lean. They concluded to have experienced no major negative impact. On the contrary, they saw an increase in team productivity during their tested lean sprints. In short, the university reports . positive results of applying lean methods to software development So, what are these bugs and wastes that companies must reduce? The Wastes In Lean Software Development 1) Inventory Waste In lean software development, is inventory waste. In essence, it fits the definition as well: a code block that is incomplete but is lying around for completion is merely occupying code inventory space. Lean principles define that developers should not leave incomplete work. However, it is not just about partial codes. Inventory wastes in software development also include: partially completed work Uncoded Documentation Unsynchronized Codes Untested Codes Undeployed Codes Undocumented Codes Solution: Strong adherence to Lean principles and Kanban methodology will limit the work process to keep the project manageable. A high number of incomplete tasks mean failure in project management which can further lead to problems in task assignments. Lean suggests that software devs assign manageable tasks and ensure their completion before handing out more. 2) Overproduction Have you ever come across a feature in a mobile app which seemed entirely useless to you? What if the same feature is useless for the majority of the app users? is the next waste in terms of lean software development and provides an excellent example. Galaxy S4 introduced the feature, which although looked promising on paper, showed a different reality. Considering the feature is no longer available in the new Samsung devices, it points to one thing: . Extra Features Samsung’s Galaxy S4 Air Gesture masses did not need it When it comes to software and web development, the client and its users are keys to figuring out the necessary features of a software. Low-value extra features that users don’t use or even use infrequently are simply waste in lean software development. Sometimes, this is a cause of software companies rushing to add features as a show of strength. In actuality, the new features remain unused, add complexity and raise maintenance costs for apps. Ultimately, the extra feature adds no value. Solution: The or the states that 80% of the users will most likely use 20% of the features. Hence, developers should aim for iterative development. The main goal should be to build an MVP and then continue to add more features as per the clients or user needs. Besides, the software development team should be ready to commit to changes in features that may come during the development phase as well. In short: Pareto Principle 80/20 Rule “Instead of worrying about how to develop stuff faster, it is far better to learn how to stop developing things that are not important and focus on the things that will have a real impact.” – The Lean Mindset: Ask The Right Questions 3) Extra Processing Extra Processing, a waste in lean manufacturing, is converted to in terms of lean software development. Relearning is the repeated learning of anything through multiple channels. Detailed documentation that no one reads or extra planning activities are some of its examples. The time, effort and resources used to create documentation that could instead be delivered verbally or through other forms of communication (verbal, email, etc) are wasted efforts. Even a simple step of rubber stamping when there is no requirement for it is a waste. Relearning Solution: Lean software development emphasizes building strong team collaboration and a healthy communication network between teams. Software teams should engage in shared learning platforms, where they can share new relevant information with other teams as well. This points towards breaking down . knowledge silos According to , are a part of the . Teams should pass information to other departments if it goes beyond their scope, including the information that is merely a thought. Unfortunately, this is a rare occurrence, and the new team members often have to lean on such siloed information to continue building. Eventually, as the team grows and more departments are added into a project, the need to disperse information evolves further. Written documentation is the only way to enable teams to grow. Stack Overflow knowledge silos “natural evolution of project growth” 4) Transportation While transportation in lean manufacturing refers to the moving activities of a product, in lean software development, we call it Handoffs. In practical terms, , or motion is the time lost in moving data from one location to another. Any time software developers transfer projects from one team to another, there is a need to generate extra work for transferring knowledge and provide training. This comes under the assumption that the knowledge transfer happens at a 100% success, and that is not possible! Handoffs As per Tom and Mary Poppendieck, companies of knowledge in every handover. This means that the leftover of the total amount that initially started to flow. lose about 50% after 5 handovers knowledge is only 3% Solution: While the transfer of knowledge itself is crucial for any project, we can reduce its negative effects. Set up policies to break down knowledge silos by integrating disparate teams into working together and adding cross-functional teams can prove effective. Additionally, communication channels like documentation, emails, voice call and in-person conversation should be given preference. Feedback loops should be quick, and iterations should be less to improve results even further. 5) Waiting Any process that stops project activity is a waste, and lean software calls it to . This waste can range from approval delays to dependencies. As soon as someone is required to approve a certain task, job, or work, waste is created. This is a bottleneck in the entire project management which restricts teams from moving forward until they obtain approval. In some cases, this can even result in rework and readjustments, especially if approval is required from clients. In short, work delay, or waiting, aspect of lean development is the time interval in which one or more team members are idly waiting for input from another party/team/individual to continue. Work Delay The figure below shows how weeks of waiting can stretch a project into several weeks. Do note that the cause of wait is not defined. Solution: The software development sector can eliminate work delays or wait by reducing handoffs . Teams should adopt a more instantaneous communication approach for approvals: prefer in-person communication or instant messaging rather than email or reminder notices. Create independent teams that are independent of approval or validation from others. This may take time for full implementation, but gives way for ease of work. There is also a need to distribute decision-making powers among members in lean software development. (discussed previously) 6) Motion Motion turns into in lean software design and to explain this, you may refer to it as a sibling to Handoff. In context switching, a programmer’s work can require them to take up multiple projects, often forcing them to jump from one project to another as per requirement. Context Switching Reality is, it requires a change in a complete mental state to bring out complex project mapping and programming work of the past before an average programmer can begin their next ongoing task. , the impact of context switching in the following way: Jeff Atwood, the co-founder of Stack Overflow explains “Even adding a single project to your workload is profoundly debilitating by Weinberg's calculation. You lose 20% of your time. By the time you add a third project to the mix, nearly half your time is wasted in task switching.” – Jeff Atwood I have also included his graphical representation below: Consequently, task switching is not something to ignore either. Left unchecked, and it can reap grave repercussions for team members as well. Take it from a who recorded that BBC Study “Those distracted by incoming email and phone calls saw a 10-point fall in their IQ – more than twice that found in studies of the impact of smoking marijuana”. Solution: Similar to how one development team can handle the waste of partial work done, they can reduce context switching by limiting the amount of work-in-progress. Again, the Kanban methodology of the Agile process is the key to limiting workflow here. Unplanned work can also introduce context switching, and it can be reduced through post-incident reviews. Individuals and teams should prioritize tasks and other teams should also be synchronized with each other’s priorities to reduce . “surprises” 7) Defects Finally, , like in lean manufacturing, are simply what they are: a waste. Similar to lean manufacturing principles, lean software development relates defective codes or bugs to waste. This is because defects cause extra work in the form of rework. They add more time to project completion and force programmers into context switching. Below is a simple equation to see its impact: defects Amount of Waste By Defect = (Impact of Defect) x (Time Passed Until Its Detection) In general, expenditures on fixing a defect in the form of time, money and manpower can be significant in the absence of proper quality checks. Moreover, defects detected at an early stage of development are easier to fix as compared to those detected during the operation phase, or even later. Solution: Mitigating defective programming, codes and bugs are what the part of the lean software development is about. It ensures quality programming and reduces rework. It promotes the practice of self and peer review strategy and ensures defect logging. Strong documentation is a key but, then again, the documentation should not result in another waste . “Build Quality In” (previously discussed!) Conclusion – Lean Software Development Is A Battle Worthy of Participation! To summarize everything, the table above can explain the defects of lean software development. The principles of lean are not just for the manufacturing and product industry. As the research above shows, it is a beneficial method of starting work for a software project. The idea to eliminate waste to increase efficiency and quality is equally important in the software development industry. It may require extra pressure to implement at all levels, but its long term results are worth taking on any challenge.