All You Need to Know About Lean Software Development

Bangalore: Lean manufacturing is all about eliminating waste. It comes from Japanese methods, primarily the Toyota Production System (TPS), which was largely created by Taichi Ohno, Toyota's chief engineer. The word lean, however, was first used by James Womack and Daniel Jones, in their 1990 book “The Machine That Changed The World: The Story of Lean Production”. Womack and Jones took the practices they observed at TPS and made them rules, calling the collection of methods lean.

The straightforward bit of the lean philosophy is ‘waste’. If you have technical staff sitting around, doing nothing, waiting for a build, that is waste. Lean software development’s aim is to minimize waste.

It would be too simplistic to view lean as a checklist of practices: apply them all, and you are successfully lean! Lean is more like a way of thinking.

Still, you could apply many of the tools which were described by Womack and Jones for lean production techniques, to software testing. The real test of lean software development is not to copy the tools listed below, but adopt a similar thought process to work towards improving the flow of value.

Generating a one-piece flow: Lean manufacturing focuses on delivering one part, end-to-end. This is referred to as one-piece flow. Similarly in development, the process should be broken down into segments and emphasis placed on finishing one segment fully.

Eliminate multitasking: To get to a one piece flow, we will limit the quantity of work being done at a time. Technical contributors (pairs) will work on one task at a time. What can a developer do when he wants to assign work, but the testers are busy?

Replacing a “push” system: As an alternative to “pushing” work to the next step, pull it, which means the testers in above level should not take on more work until they are ready for it. Pulling work in the example above would be detrimental to the work in progress. So programmers must figure out how best to help the testers. This could be by doing testing themselves, or by writing test tools. Rather than making a fuss over a bottleneck, you try to fix it and increase your throughput.

Eliminate pointless motion: Imagine a huge pile of candies placed at your doorstep and you have to sort it into five boxes. You will pick as much as you can from your doorstep, walk towards the five boxes, sort them, walk back to retrieve another bunch and repeat the whole process many times. Instead you could make things simpler if you bring the boxes to the doorstep and sort the candies. In software, these maybe compilers, databases, continuous improvement (CI) frameworks and version control-but the concept remains the same. Programmers have to work with code on different environments, on build systems that take too much time and changes in design sent via email. If your technical staff has queries and have to wait hours or days for a reply, again you have an issue. The lean software solution would be to get the person who can answer the query into the room. This could be by pairing new programmers with more experienced staff so they don’t get stuck.

Reducing scrap: Limit the number of defects that reach the production stage and try to prevent them from reaching the tester. If indeed it does reach the tester avoid the usual process where a tester must find a defect, stop it, reproduce the problem, document it, pass it back to a developer to fix, wait and then retest. Instead, maybe the tester could work with the developer to fix the defect and avoid all the red tape.

Focus on constant progress: Continuous improvement will rely heavily on change and differentiation. For constant progress to be a fundamental value of lean, teams must be allowed to modify the process over time to improve the output. Hence standards are like guidelines which the team defines and when they are more unfavorable than beneficial, they may be dropped.

These pointers were simply a way of thinking at that time. They aren’t perfect. Ten years after lean was introduced to the software community, new tools have been emerging that allow teams to reduce waste further. Automatic build tools, cloud computing and software as a service can all increase performance by reducing the time which is spent waiting. As time passes, one can expect to see many lean software implementations, not tied to the rules of Toyota in 1986 but instead to the critical success factors of the organization.