In the 1930s, the Toyota Production System gave us lean manufacturing principles. 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.
A Brief Look At Agile And Lean Software Development
Agile development’s primary concern is to raise adaptability. The Agile Manifesto 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:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change than following a plan.
Lean development, 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:
- Inventory
- Overproduction
- Extra-Processing
- Transportation
- Waiting
- Motion
- Defects
All credits to Mary and Tom Poppendieck and their book, Lean Software Development: An Agile Toolkit. The world of software development and web design now knows the significance of analysing every process for efficiency.
Why Move To Lean Software Development?
Let’s take a look at research by the Turiba University’s Department of Business Administration. They report that about 73% of companies under study saw improvement in product quality by adopting a lean system. One example is the Timberline Software in Oregon, which also reported improvement in quality back in 2002 after adopting a lean model.
Perhaps BBC Worldwide might sweep all arguments. Under their several improvements, they experienced a 47% less variance and saw a 37% increase in software delivery. Impressively, their improvement in software delivery speed did not affect their product quality. In short, their mean number of bugs declined and the number of 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, partially completed work 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:
- 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? Extra Features is the next waste in terms of lean software development and Samsung’s Galaxy S4 provides an excellent example. Galaxy S4 introduced the Air Gesture 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: 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 Pareto Principle or the 80/20 Rule 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:
“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 Relearning 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.
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 Stack Overflow, knowledge silos are a part of the “natural evolution of project growth”. 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.
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, Handoffs, 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!
As per Tom and Mary Poppendieck, companies lose about 50% of knowledge in every handover. This means that after 5 handovers the leftover knowledge is only 3% of the total amount that initially started to flow.
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 Work Delay. 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.
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 (discussed previously). 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.
6) Motion
Motion turns into Context Switching 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.
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. Jeff Atwood, the co-founder of Stack Overflow, explains the impact of context switching in the following way:
“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 BBC Study who recorded that “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:
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, defects, 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:
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 “Build Quality In” 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 (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.