7.3 Lean Software Development


Lean software development techniques seems to be applicable and adaptable to research and experiment projects, because their similar nature. As Poppendieck et al wrote, software is not a production process but a development process. Let’s imagine

 a chef is developing a new recipe (development)


 somebody is preparing the dish by following a recipe published in a book (production):


Development: designs the recipe ↔ Production: produces the dish

  • Quality is fitness for useQuality is conformance to requirements
  • Variable results are goodVariable results are bad
  • Iteration generates valueIteration is unnecessary

 Software development is much more “receipt” development than production. This is the main reason (root cause) for the popularity and wide acceptance of agile and Lean methods in this field. The same seems to be true for any kind of research experiment (physics, biology, chemistry, etc.).


Eliminate Waste

  • The fundamental Lean principle
  • 1940s, Toyota, Japan: how to make cars in small quantities but keep them as cheap as cars of mass production?
    • Answer: eliminate waste
  • New definition: Something that not conveys any value is considered as waste
    • Transportation, motion, waiting for something, any extra step, defects
  • Deliver the product immediately after the customer placed her order
  • For example in the context of software development:
    • Software functionality that has never or very rarely been used
    • Unnecessary delays
    • Ambiguous requirements (and any kind of ambiguous documents)
    • Unnecessary repetition of the same activity
    • Slow communication
  • First step: How to recognize waste? It is absolutely not easy to do and several times trivial things are not recognized as waste (can’t see the forest for the trees situation)
    • Value Stream Mapping technique
  • Next steps, iteratively: eliminate waste (from the big to the small) and look for waste again
  • The seven wastes



Software development


Partially Done Work

Extra processing

Extra Processes


Extra Features


Task Switching








Amplify Learning

  • Software development is a continuous learning process, it is a discovery (just think about the chef and the receipt example)
    • Iteration is a key factor in learning
    • We also need good feedback from good sources to be able to learn
  • Challenge: large and complex projects, several developers
    • Parallel developments have to be synchronized


Decide as late as possible

  • Software development usually conveys significant uncertainty (like a research activity)
  • Delay decisions to avoid bad and speculative decisions too early: in the beginning there is almost zero information about the software development project
  • Collect enough information and facts and make the decisions based on them (instead of deciding based on uncertain predictions & assumptions)
  • Develop several options and choose the best one as late as possible based on the collected information


Deliver as fast as possible

  • Developers get the most information and feedback if they deliver very fast and frequently
  • Therefore this principle feeds the “decide as late as possible” and “amplify learning” principles
  • Moreover, current needs are satisfied, not obsoleted ones


Empower the team

  • Technical people (developers, testers) must be involved into technical decisions
    • Because only they are knowing all the relevant (and irrelevant) details should be considered in a decision
  • People should not be considered as resources, they have to be motivated (clear targets, tasks, etc.)


Build integrity in

  • Perceived integrity: external integrity of the system, user interface, delivery, deployment, intuitiveness, problem solving, customer perception
  • Conceptual integrity: internal integrity of system, maintainability, flexibility, etc
  • Refactoring, testing


See the whole

  • Experts in a specific area tend to maximize their own part (web service, database, UI, etc.)
    • Locally optimized solutions (faster, cheaper, etc.) could cause big problems and bugs at system level
  • Think about the whole system and the integration of different parts before local optimization