Quizá sea por aquellas cosas con las que de pequeños nos educaron e inculcaron, esas maneras de hacer, aparentemente las más correctas, “buenas prácticas” que se te quedan grabadas en la mente y de las que hoy es difícil escapar sino es por profundos razonamientos, será por frases que la sabiduría popular ha hecho “incuestionables”, como el “no dejes para mañana lo que puedas hacer hoy”, será por eso, o yo que sé por qué, que en 233 Grados de TI hay un debate recurrente casi desde su nacimiento: siempre acabamos decidiendo cosas en el último momento y nuestra mente, la conciencia, nos dice que eso no está bien, así nos han educado, pero nuestro instinto nos dice que no nos va nada mal haciéndolo así.
Y parece que no estamos locos pensando y actuando así, no, nada, y que, cómo no, esta manera de trabajar ya había sido objeto de profundo estudio en el mundo del desarrollo software, implícita en Agilidad y Lean.
En 1988 Harold Thimbleby publicó en IEEE Software un artículo titulado «Delaying Commitment» (algo así como retrasando los compromisos), que además fue tomado como base en el popular libro Lean Software Development (capítulo 3, allá por la página 56).
Según Harold había apreciado, 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, 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.
Según Thimbleby, llegar a compromisos de manera prematura restringe el aprendizaje, agrava el impacto de los problemas y aumenta el coste del cambio.
Un proceso ágil, y Lean (como cita el libro que antes te comenté, el Lean Software Development) igualmente, sigue esta filosofía de trabajo, se comienza a trabajar cuando sólo se conocen requerimientos parciales y trabajar en iteraciones cortas proporciona la retroalimentación para mejorar la toma de decisiones. Un ciclo de vida en cascada está en el polo opuesto.
En un proceso ágil, es típico retrasar el compromiso hasta el “last responsible moment” (último momento responsable, que he dejado en inglés ya que el término existe, creado Lean Construction Institute), es decir, hasta el momento en el que dejar de tomar una decisión elimina una importante alternativa.
Según esto, se pueden tomar mejores decisiones “no decidiendo”. Y no sé a ti, pero a nosotros en 233 Grados de TI, haber profundizado en el tema del “retrasa las decisiones” no nos ha cambiado la manera de trabajar, ya lo hacíamos así, y me temo que iba a ser difícil cambiarlo, pero si que nos ha eliminado problemas de “remordimiento de conciencia”.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024