En 2003, Tom and Mary Poppendick escribieron su famoso libro Lean Software Development: An Agile Toolkit basado en las experiencias de Tom y Mary. Tom era desarrollador software y Mary trabajó en una fábrica donde se usaban métodos de Lean y del Toyota Production System.

En este libro Tom y Mary definen siete principios básicos del Lean Software Development:

• Eliminar desperdicios (Eliminate waste) considerando a éstos en la industria del software como los defectos o bugs que se puede incluir por error en el código. También se considera residuo o desperdicio a las funcionalidades y características extras incluidas en el producto y que no se necesitaban o no se usan (Over production). Estas funcionalidades no habrían sido incluidas si se hubiesen seguido los principios KISS (KeepIt Simple, Stupid) y YAGNI (You Aren’t Gonna Need It). Otros desperdicios en la producción son:
  • Las esperas (Waiting): Se producen cuando no se tiene la suficiente información o los elementos necesarios para terminar la tarea.
  • Procesos no estándares: Diferentes miembros del equipo usan diferentes métodos para realizar una misma tarea.
  • Transporte (Transportation): Cuando documentos o cualquier tipo de elemento debe ser transportados de un lugar a otro. Por ejemplo, cuando se necesita una copia de seguridad de una base de datos y el volumen de datos es tan grande que no se puede transmitir vía Internet. Podría ser necesario enviar por correo un dispositivo de almacenamiento hasta el centro de datos físico donde están los servidores, para luego transportar la copia físicamente hasta el origen.
  • Intelecto: Cuando el conocimiento y cualificación de un miembro del equipo de trabajo no es utilizado en las tareas donde se le podría sacar más provecho. Está asignado a tareas inferiores donde no se obtiene tanto rendimiento.
  • Movimiento (Motion): Aquel que se realiza cuando se tiene, por ejemplo, que mover documentos en papel hasta un archivador para luego volver a ir a buscarlo cuando se necesita.
  • Exceso de inventario: Cuando se ha creado demasiada documentación, cuando la bandeja de entrada de emails está demasiado llena o cuando se tienen demasiadas llamadas de ventas esperando.
• Aumentar el aprendizaje (Amplify Learning): Usar cualquier método al alcance para poder aumentar el conocimiento sobre el producto y los usuarios o el mercado que lo va a usar. Podrían utilizarse, por ejemplo, test automatizados, que permitirán aprender mejor sobre los errores del software. Puede también aumentarse el aprendizaje con la integración continua. De esta forma no se espera a la integración final de todo el software para saber si hay partes que funcionan bien con las otras o no.
• Retrasar el compromiso (Defer the commitment): Decidir lo más tarde posible. Cuanto más se haya avanzado en la producción del sistema, más se sabrá de él por lo que se cometerán menos errores al decidir.
• Entregar rápido (Deliver fast): No retrasar la entrega de software hasta la finalización del proyecto. Entregar versiones previas cuantos antes. Permitirá aumentar la satisfacción del cliente que recibirá antes su Retorno de la Inversión (ROI) y aprender mejor lo que el cliente usa o no.
• Respetar a la gente (Respect the people): Dejar que los miembros del equipo de trabajo tomen sus propias decisiones, respetarles y potenciar sus individualidades. Se conseguirá un mejor ambiente de trabajo, que se sientan considerados y que se animen a aportar ideas y soluciones que de otra manera no se tendrían.
• Incorporar la calidad (Built quality in): No usar la calidad como una etapa al final de la construcción del producto sino incorporarla en todas las fases del desarrollo. Mantener la calidad siempre presente. El objetivo es prevenir la introducción de errores que haya que corregir posteriormente.
• Optimizar el conjunto (Optimize the whole): En lugar de optimizar pasos o tareas individuales del proceso de desarrollo de software debe intentarse optimizar el flujo completo de este proceso.