Lean Software Development – Eliminating Waste

There is nothing so useless as doing efficiently that which should not be done at all. --Peter F. Drucker

Lean is a generic process management philosophy derived from the Toyota Production System. The Japanese term for waste is “Muda”. Eliminating waste is the very first step of going Lean. Here are some thoughts on eliminating waste in Agile Software Development for various activities:

Requirements:

• Agile advocates User Stories (as opposed to Use Cases). User Stories capture the high level Goal for a feature/function in one or two sentences in the product backlog. A conscious attempt is made to avoid too much detail. The details are worked out just-in-time during the development. This prevents premature optimization and over engineering of requirements.

• Specify Acceptance Criteria for each user story. Acceptance Criteria is very effective to communicate requirements to developers and discourages gold plating of requirements.

• Slice major user stories (epics) into multiple smaller manageable user stories. Develop the sub features in order of priority. Release something of value to the end user in every sprint. Receive feedback and adapt accordingly in the next sprint.

• Make a conscious attempt to avoid feature bloat (Swiss-Army-Knife approach) as much as possible. Increased complexity increases defect density, compromises usability, makes unhappy customers and drain development team’s resources.

Design:

• Agile teams do not treat design and development as separate silos. Both are integral to each other.

• Avoid elaborate design documents unless when working on very complex features. Live meetings/interactions are more effective for brainstorming design challenges and communicating design decisions.

• Avoid over engineering (use adaptive design as opposed to predictive design). Adopt Refactoring and continuous integration to evolve the design/code over time.

Development:

• Avoid multitasking. Work on one task at a time. Testing must be complete and the task should be ready for release before considering it ‘done” and moving on to the next task. It is important for everybody in the team to agree on a common definition of “Done”.

• Too much work in progress (inventory) in the development branch (code changes which were never released because other work got higher priority) will impede future work. Remove unreleased/incomplete code changes from version control for tasks which were interrupted/de-prioritized midway. Create patch files to preserve (hibernate) the code for future use if necessary.

• Check-in code regularly to version control to avoid last minute integration issues and resulting rework.

• Encourage collaboration (collective code ownership by the team as opposed to individual code ownership).

Testing:

• Do not waste time on elaborate test plans unless the customer mandates them. Keep test plans lean. In my last 14 years in Software development I have seldom seen anybody reading them!

• Keep test cases lean and focused. Avoid too many step by step instructions/details. Otherwise you will get lost in the details and generate useless paperwork. Scripted test cases usually exercise the happy paths.

• Automate regression testing of critical features/functionality which change/evolve frequently.

• Adopt a balanced diet of scripted and exploratory testing.

• Involve the testers from the beginning.

Planning:

• Do not overburden the team. Overworked teams are not effective in producing quality software. Overburden (“Muri” in Japanese) is one of the three types of waste identified in the Toyota production System. We all know how bumper to bumper traffic brings our highways to a standstill! Developers need down time to retrospect, reflect and improve.

• Processes/methodologies are only means to an end (working software). Always keep the end result in mind. Optimizing individual steps (doing things right) may not always lead to the right outcome (doing the right things). So we need to take a holistic look at value creation throughout the entire development process and eliminate non-value added activities as much as possible.

"The most dangerous kind of waste is the waste we do not recognize."
- Shigeo Shingo (Toyota)