En 2003, Mary Poppendieck publicó un artículo titulado «Lean Development and the Predictability Paradox», que aún puedes encontrar online y en abierto aquí (ya te lo puedes ir bajando y leyendo). Y ahí, apareció la “paradoja de la predictibilidad”, que luego acabó como capítulo en el libro Implementing Lean Software Development: From Concept to Cash (Myth: Predictions Create Predictability).
La paradoja de la predictibilidad, como lo explican Mary y Tom Poppendieck, es que el objetivo de mejorar la previsibilidad del desarrollo de software (mediante estimaciones, fechas de entrega a largo plazo, planificaciones detalladas, etc.), ha llegado a institucionalizar prácticas que han tenido el efecto contrario. Hasta el punto de que que creamos planes y luego actuamos sobre ellos como si representaran una predicción exacta del futuro.
Y dicho esto, aparecen, como siempre ha pasado en el mundo del software, dos estrategias: una trabajar, estudiar, crear, etc., maneras de intentar que los planes sean exactos (predictivilidad, ingeniería del software clásica) o trabajar bajo la premisa de que los planes no son muy precisos y tienen alta probabilidad de cambio, y establecer una estrategia en base a ello (cambiabilidad, agilidad, Lean software, etc.).
Según esto, podríamos pensar hasta que tener planes no es el mayor problema, quizá el mayor problema es asumir que no están equivocados.
La paradoja es que al intentar crear predecibilidad creamos efecto opuesto: Introducimos prácticas que dan falsa seguridad y que no logran resultados predecibles.
La paradoja del Lean aplicado al software, y de la agilidad, es renunciar a prácticas de predictibilidad con el fin de obtener una verdadera predictibilidad. Fundamentalmente, desarrollando la capacidad de responder al cambio, en lugar de mantener la rigidez y el objetivo de adivinar qué pasará a largo plazo.
Comenta el artículo de Poppendieck que la mejor manera de lograr buenos resultados en software se basa en 4 principios, que van en contra de la gestión de proyectos tradicional:
Comenzar cuanto antes
Sin esperar a tener toda la información, todos los detalles. Comienza ya, a qué esperas. Si esperas a detallar y detallar todo antes de empezar empiezas a crear barreras, sustituir comunicación cara a cara por documentación, a crear falsa seguridad. Nada como ponerse ya, para empezar a aprender.
Aprender constantemente
A lo que ayuda el principio anterior, cuanto antes empiece antes voy aprendiendo sobre realidades.
Llegar a compromisos lo más tarde
Aunque este principio lo toma Poppendieck, el autor fue Harold, de esto te hablé en Lo de “no dejes para mañana lo que puedas hacer hoy” puede ser una mala estrategia de gestión, y viene a decir que los expertos, cuando se enfrentan a una nueva situación, retrasan las decisiones en firme, mientras investigan la situación y lo hacen porque saben que el retraso de los compromisos, a menudo, les lleva a adquirir nuevos conocimientos con los que tomar una mejor decisión final.
Los novatos (y no tan novatos), en contraposición, quieren tener todo cerrado cuanto antes, por lo que tienden a tomar decisiones en momentos demasiado tempranos, tomando a menudo decisiones incorrectas. Una vez tomada una decisión temprana, esto lleva a tomar más decisiones inapropiadas en base a esta primera decisión.
Entregar lo más rápido
No tiene sentido llegar a acuerdos lo más tarde posible si no eres capaz de entregar lo más pronto posible. Entregar cuanto antes, aunque sea por partes, incrementa el conocimiento y ayuda a tener más información para llegar a compromisos más fiables.
Y esto apareció en el contexto del desarrollo software, pero te aseguro yo, y supongo que ya te habrás percatado de ello, que aplica a muchos más aspectos de tu vida y dedicaciones que el puro desarrollo software.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Creo q ningún extremo es bueno, ni detallar todo antes de empezar, ni largarse sin tener nada prefijado tampoco. Todo dependerá del lugar, la celeridad y el equipo para lograr el equilibrio apropiado de un modelo hibrido.