The Predictability Paradox

Viendo en YouTube la charla de Ángel Medinilla sobre Contratos Ágiles se menciona como referencia de interés el artículo escrito por Mary Poppendieck "Lean Development & the Predictability Paradox". Se trata de un gran artículo, en todos los sentidos, tanto en extensión (39 páginas), como en las ideas que en él se transmiten. Ideas, sencillas, pero potentes a la vez, extraidas de Lean Manufacturing y su práctica en la marca japonesa Toyota.
Todo el artículo gira alrededor de lo paradójico que puede resultar intentar alcanzar la máxima predictabilidad en un proyecto software. Como dice la autora: "La paradoja es que intentar con demasiado esfuerzo crear predictabilidad origina el efecto opuesto".

El camino propuesto comprende los siguientes principios: comenzar pronto, aprendizaje constante, comprometerse lo más tarde posible, y entregas rápidas.Y a su vez, estos principios se apoyan en cuatro focos adicionales: eliminar todo aquello que no aporta valor ("waste", pero he preferido no buscar traducción directa a esta palabra), fortalecer la autoridad del equipo de trabajo, integración completa del testeo dentro del propio desarrollo, evitar la sub-optimización descomponiendo el todo en partes más pequeñas.

Algunas de las principales ideas con las que yo me quedo son las siguientes:

- Los usuarios tienen dificultad para articular claramente lo que ellos necesitan, y las necesidades de los usuarios cambiarán una vez que ellos vean el potencial del sistema y entiendan lo que pueden llegar a hacer con él. Por ello, de la importancia de comenzar a desarrollar lo antes posible.
- Si dividimos un problema complejo en partes más pequeñas, resultará mucho más difícil centrarnos en el campo de actuación en el cual dicho problema existe, porque el esfuerzo se estará dirigiendo hacia solucionar los sub-problemas. En ese aspecto el desarrollo Lean trabaja con un enfoque de "embudo": se comienza explorando la amplitud del paisaje, para ir luego gradualmente estrechando el campo de visión.
- Los planes están basados especulaciones, puesto que realmente no conocemos todo lo necesario cuando estamos creando el plan del proyecto. Puesto que hay que asumir los cambios como algo totalmente natural en un proyecto de software, debemos tener "feetback" constante en el proceso de desarrollo, puesto que en caso contrario estaremos desarrollando para situaciones que existieron al principio del plan, pero no cuando el software se vaya a entregar.
- Retrasar los compromisos, significa mantener abiertas las opciones posibles tanto tiempo como sea posible. Como se comentaba antes, las decisiones se deben basar en hechos, y no en proyecciones. Como comenta Mary Poppendieck en el artículo: "La decisiones se deberían hacer en el último momento responsable: el momento en el que un fallo en la toma de decisiones elimina una alternativa importante". Para ello, es importante también tener una capacidad de respuesta muy rápida.
- Hay que proporcionar autoridad y poder decisión al propio equipo de trabajo, puesto que realmente una planificación que pueda cambiar de forma rápida es mejor implementada por ellos, que adoptando una planificación centralizada.
- En el pensamiento lean, la eliminación de cualquier cosa que no añada valor ("waste") es el punto clave para conseguir la excelencia. Y en este sentido, es necesario revisar aquellos puntos de la cadena donde el trabajo permanece parcialmente hecho.
- La creación de defectos es "waste" en proporción directa al tiempo que el defecto permanece en el sistema. Por eso es tan importante que los defectos creados, sean detectados y solucionados inmediatamente a través del testeo.
- Una gestión efectiva del equipo de trabajo pone el énfasis en que éstos definan y constantemente mejoren sus propios procesos. Ésto debe marcar la diferencia entre rendimiento pésimo y resultados estelares. Se asume que el equipo de trabajo conoce su trabajo y los problemas derivados mejor que nadie. Es muy importante tener un buen método para tranferir conocimientos y experiencia entre todos los miembros del equipo, del tal forma que nadie sea indispensable.
- En cuanto al testeo, éste debe estar completamente integrado dentro del proceso de desarrollo. Se dice en el artículos que cualquier sistema de software que pueda sufrir cambios en el futuro debería tener un completo conjunto de tests automatizados, del tal forma que cuando se realicen cambios, sea imposible romper el resto del sistema. Es indispensable que el sistema sea testeado en las mismas condiciones en las que se encontrará en el entorno real de producción.
-La desagregación en tareas ignora el flujo de valor a través del conjunto completo de la cadena económica. Se centra en el coste y tiempo de hacer cosas, pero no considera el valor de no estar haciendo nada. La autora critica en este apartado, la creación de la Estructura de Desglose del Trabajo (Work Breakdown Sctructure,WBS) propuesta en la gestión de los proyectos convencionales, porque se centra en la gestión del coste y la planificación de cada parte de forma individual. En este sentido, también, se aconseja medir el redimiento del equipo completo, más que tratar de medir el rendimiento individual de cada miembro.
- Mary Poppendieck defiende la idea de que cada proyecto debería tener su propio cuadro de mandos que reflejase los principales conductores de valor de negocio, en vez de medir los proyectos en coste, planificación y alcance. Esos indicadores son lo que realmente deberían dictar el éxito o no del proyecto.
- En cuanto a los contratos se defiende que hay que buscar en todo momento la maximización de beneficios proveedor-cliente, y en este sentido los "Targets Contracts" son un buen mecanismo para conseguir dicho objetivo. Se trata de un tema que me gustaría desarrollar en otro post, porque realmente hay materia para muchos ríos de tinta. Recomiendo además, ver la charla de Ángel Medinilla que al principio de este post se mencionaba.

Hasta aquí un repaso de las ideas con las que yo me quedo de este gran artículo. Ideas con las que mayoritariamente estoy de acuerdo. No estoy de acuerdo en la visión que se proporciona en el artículo de la WBS, porque considero que el objetivo perseguido por su realización puede ser totalmente compatible con la visión a más bajo nivel (a nivel de implementación) perseguido por lean. Y en general hay otras ideas propuestas en el artículo, que se tratan totalmente opuestas a la visión que, por ejemplo, el PMI traza de la gestión de proyectos, pero que bajo mi punto de vista son totalmente complementarias. Pero, efectivamente, sobre estos temas también hay mucha materia para escribir.