Mary Poppendieck: Deja de alimentar la cola

10 min de lectura

Hizo imposible ignorar la espera

Lean no llegó como un disfraz de fábrica para el software

Mary Poppendieck no descubrió Lean en un catálogo de certificaciones para luego pegar vocabulario de fábrica sobre un backlog. Empezó como programadora de control de procesos, después dirigió tecnología de la información en fabricación y trabajó en desarrollo de productos. En su relato de esa trayectoria, describe sus primeros trabajos de programación en Bell Labs, controles automatizados de vehículos en General Motors y sistemas de control para las máquinas que fabricaban cinta adhesiva en 3M.

Esa historia importa porque nunca sostuvo que el software debiera convertirse en una cadena de montaje. Desarrollar software implica descubrir cosas. Mientras construyen, los equipos aprenden qué necesitan los clientes, qué puede soportar el sistema y qué supuestos eran falsos. La lección útil de Lean consistía en organizar ese aprendizaje para que avanzara, en vez de enterrarlo bajo trabajo acumulado, traspasos y compromisos prematuros.

Mary y Tom Poppendieck dieron forma duradera a esa adaptación con Lean Software Development: An Agile Toolkit en 2003. Después publicaron libros sobre implantación, liderazgo y mentalidad Lean. Su trabajo conectó valor para el cliente, flujo, calidad, aprendizaje, respeto por las personas y visión del sistema completo. También dio a los responsables del software palabras para un problema que ya sentían: todo el mundo parecía ocupado, pero el negocio esperaba meses para obtener respuestas.

La mayor parte del tiempo, el trabajo espera

En su análisis de 2005 sobre la supuesta disyuntiva entre calidad y velocidad, Poppendieck describe cómo trazar el recorrido desde una petición del cliente hasta el software desplegado. En los mapas del flujo de valor realizados en sus cursos, normalmente se trabajaba en la petición durante menos de una quinta parte del tiempo total. El resto lo pasaba esperando en una cola.

Ese patrón resulta dolorosamente fácil de reproducir. Un cambio en un proceso de trabajo espera una decisión de producto. La decisión se convierte en una tarea y espera un equipo. El código espera revisión. La revisión revela una duda de integración y el trabajo espera al proveedor. Las pruebas empiezan al final, encuentran un defecto y devuelven el cambio al mismo circuito de obstáculos. Cada departamento puede declarar una ocupación respetable mientras el cliente no recibe nada.

La dirección suele responder metiendo aún más trabajo en el sistema. Ampliar el alcance. Arrancar otra iniciativa. Pedir que cada especialista esté ocupado al máximo. Comprar una herramienta de IA para que los desarrolladores produzcan código más rápido. Las colas crecen, aumenta la coordinación y se alarga el tiempo de entrega. Entonces alguien organiza un taller sobre velocidad del equipo.

La respuesta Lean tiene menos teatro. Limitar lo que entra en el sistema. Terminar un cambio pequeño y valioso. Ver dónde espera. Eliminar ese cuello de botella. Repetir.

Eso no convierte automáticamente en Lean un tablero lleno de tarjetas de colores. Un tablero puede mostrar un atasco con una uniformidad visual admirable. El trabajo solo avanza cuando la organización cambia las condiciones que generan el atasco.

La productividad local puede perjudicar las entregas

La mayoría de las organizaciones miden las piezas porque es fácil asignar un responsable a cada una. Los analistas deben producir más requisitos. Los desarrolladores deben cerrar más tareas. Los responsables de pruebas deben encontrar más defectos. Operaciones debe proteger la estabilidad reduciendo las versiones. Compras debe rebajar las tarifas de los proveedores. Cada área puede alcanzar su objetivo mientras las entregas se hunden entre ellas.

La alternativa de Poppendieck es optimizar el conjunto. Lo que importa es el recorrido desde la necesidad hasta el resultado útil, incluidas las decisiones de negocio, el desarrollo, las pruebas, el despliegue, las operaciones, el soporte y el aprendizaje a partir de los clientes. Su ensayo sobre productividad en el desarrollo de software sostiene que la productividad útil consiste en convertir ideas en software valioso con eficacia, en vez de contar cuántas líneas de código produce la gente.

Imagina una empresa de logística que automatiza la gestión de incidencias. Operaciones sabe qué casos arruinan una mañana. Un proveedor controla la plataforma de transporte. Un desarrollador interno mantiene la integración. Finanzas controla las reglas de compensación. Si cada parte trabaja desde su propia cola, la empresa consigue una actividad impresionante y un aprendizaje lento. Nadie responde por el resultado completo.

Reúne a esas personas alrededor de un resultado pequeño que recorra el sistema: detectar una incidencia costosa, dirigirla correctamente, verificar el resultado y observarlo en uso. Los límites del software quedan a la vista. Las decisiones también. El equipo puede aprender si la automatización ayuda antes de programar cada incidencia imaginable en una pequeña burocracia privada.

Así funciona el flujo de software cuando el principio de gestión llega al código y a la organización del trabajo. Mejora todo el recorrido o el cliente sigue esperando.

La calidad pertenece al flujo

Lean se mutila con frecuencia hasta convertirlo en un lema de recorte de costes. Quitar personas, reducir márgenes, exigir más producción y llamar eficiente a la fragilidad resultante. El trabajo de Poppendieck apunta en sentido contrario. La calidad debe incorporarse al trabajo porque los defectos descubiertos tarde crean colas, retrabajo y aprendizaje tardío.

Su ensayo de 2005 acerca las pruebas a la programación, con integración frecuente y comprobaciones automatizadas. El principio va más allá de una práctica concreta de pruebas. Encontrar la incertidumbre donde aparece. Convertir una regla de negocio en un ejemplo mientras están disponibles quienes la entienden. Comprobar una integración mientras el cambio sigue siendo pequeño. Hacer que desplegar sea tan rutinario que el día de lanzamiento no requiera un comité y viento a favor.

Aquí la historia de Mary Poppendieck se encuentra con los ciclos cortos de feedback de Kent Beck. Beck aporta el ritmo de desarrollo: probar, cambiar, refactorizar, aprender. Poppendieck amplía el enfoque. Si el cambio probado todavía espera doce días para obtener aprobación, la organización ha protegido una parte del flujo y ha descuidado el conjunto.

La velocidad y la calidad no son enemigas naturales. La demora y los descubrimientos tardíos hacen que lo parezcan. Acercar la evidencia a la decisión permite que un equipo avance más rápido porque pierde menos tiempo construyendo, transfiriendo, redescubriendo y reparando lo equivocado.

Decide antes de perder una opción valiosa

El control tradicional de proyectos prefiere la certeza temprana. Especificar todo el proceso de trabajo. Seleccionar la plataforma. Fijar el diseño de integración. Estimar el programa completo. Encarecer los cambios hasta que la gente deje de mencionar lo que ha aprendido.

El desarrollo Lean trata la certeza prematura como desperdicio. Una decisión tomada antes de disponer de la información necesaria es solo una conjetura con fecha límite. Poppendieck defendía posponer los requisitos detallados hasta estar más cerca de la implementación, cuando el equipo sabe más y puede evitar mantener una cola de cambios sobre conjeturas antiguas.

Es fácil abusar de esta idea. «Decidir después» no puede ser permiso para dejar bloqueado a un equipo mientras los directivos evitan una elección incómoda. El último momento responsable está justo antes de que la demora cierre una opción valiosa, no la tarde posterior a su desaparición. Los equipos necesitan límites claros, acceso rápido a quienes deciden y pequeños experimentos que aporten mejores pruebas.

Para un nuevo proceso de gestión de siniestros asistido por IA, eso podría significar fijar pronto los límites de privacidad, la trazabilidad y la capacidad de intervención humana, pero aplazar la elección del framework de orquestación. Probar el tipo de siniestro más arriesgado con quienes lo tramitan. Aprender dónde falla el modelo. Conservar la posibilidad de sustituirlo. La arquitectura debería permitir aprender antes de imponer decisiones permanentes.

La IA puede alimentar la cola a velocidad de máquina

Las herramientas de programación con IA hacen más relevante la lección de Poppendieck. Pueden reducir el tiempo necesario para producir una implementación plausible. Programar más rápido no resuelve una decisión de producto, ni concilia departamentos, ni concede acceso a producción, ni repara una relación con un proveedor, ni establece qué fallos puede aceptar el negocio. Las herramientas pueden ayudar con ese trabajo. La autoridad y la responsabilidad siguen necesitando a alguien que las asuma.

Si un equipo ya tiene veinte cambios esperando revisión, generar cuarenta más no es acelerar. Si los despliegues son mensuales porque el sistema es frágil, programar más rápido añade trabajo acumulado. Si nadie responde por una herramienta interna creada con IA cuando su creador cambia de empleo, la organización ha producido software sin producir un servicio.

Esta es la forma moderna de optimización local. Se programa más rápido, así que la dirección declara que todo el sistema entrega más rápido. La realidad presenta la factura completa: más revisión, más pruebas, más dependencias, más comportamiento que atender en producción y más conjeturas que alguien tendrá que descartar.

La pregunta útil no es cuánto código produjo el agente. Pregunta si un cambio valioso llegó antes al uso, con suficientes pruebas para confiar en él y responsables capaces de mantenerlo. Cuando la IA hace que una empresa sea responsable de software, el pensamiento Lean evita que la producción barata se convierta en un atasco caro.

La decisión de la dirección

Un CTO no arregla el flujo pidiendo a los desarrolladores que se concentren más. Algunos cuellos de botella están en el código. Otros están en los presupuestos, las estructuras de aprobación, los límites entre equipos, los contratos con proveedores, las políticas de lanzamiento y la indecisión de los directivos. La dirección responde por las condiciones que rodean al trabajo.

Empieza con una petición que importe. Sigue su recorrido desde que el negocio la plantea hasta que alguien utiliza el resultado. Cuenta la espera. Encuentra los traspasos. Pregunta por qué se prueba donde se prueba. Observa qué decisión no tiene responsable y qué especialista se ha convertido en parada obligatoria para cada cambio.

Después elimina un cuello de botella real. Reduce el trabajo en curso. Reúne a quienes construyen, operan y usan el sistema alrededor del mismo resultado. Da a un equipo autoridad sobre un servicio que pueda entender y mantener. Adelanta las comprobaciones de calidad. Rompe una dependencia en vez de añadirle una ceremonia de coordinación.

Poppendieck advirtió en 2019 contra las transformaciones perseguidas como fines en sí mismas. Las organizaciones no necesitan «hacer Lean» como nueva identidad. Necesitan productos y servicios que los clientes valoren, un entorno de trabajo que aproveche el criterio de las personas y un sistema de entrega capaz de aprender antes de que el mercado termine de darles la lección.

Su aportación duradera fue hacer visible la demora. Un equipo puede parecer ocupado mientras el valor se muere de hambre en una cola. Cuando los responsables lo ven, seguir alimentando esa cola se convierte en una elección.

Referencias

• An Interview, Mary Poppendieck
• Software Development Productivity, Mary Poppendieck
• Breaking the Quality-Speed Compromise, Mary Poppendieck
• Biografía de la autora Mary Poppendieck, O’Reilly
• Lean Software Development: An Agile Toolkit, Addison-Wesley
• Implementing Lean Software Development, Addison-Wesley