Lo difícil de interiorizar el fracaso como buena práctica

Otra vez me ha pasado, ha vuelto a suceder.
En este caso eran un par de personas listas, válidas, con experiencia y mente abierta, conocedoras de lo que es agilidad, Lean y otros seres y estares.
Todo comenzó así. Arranca un nuevo proyecto, bueno, ni siquiera había comenzado como tal, se estaba en los primeros planteamientos, en los preámbulos. Entonces, al que podríamos etiquetar como usuario, o el de negocio, llega y hace un primer planteamiento, y casi intento, de escribir todos los requisitos antes de que se empiece todo. Hasta cierto punto es entendible que él lo plantee, no tiene porque ser un experto en gestionar proyectos tecnológicos, sólo sabe, o piensa que sabe, lo que quiere.
Pero sigamos con los sucesos entendibles, posteriormente, el equipo de personas que iban a desarrollar el proyecto, le quitan la idea de tal planteamiento, mejor “vayamos poco a poco”, “incrementos”, “iteraciones”, “así podemos ir adaptando las necesidades”, “evitemos desperdicios”, y otros tantos que ya seguro conoces. Hasta ahí íbamos bien.
Y ahora viene lo bueno. El equipo técnico le pide al usuario una primera lista, breve, de necesidades, llámalas, si quieres, historias de usuario, hasta ahí seguimos bien. Y resulta, como suele ser habitual, que algunas eran de implementación facilona, que no eran demasiado importantes para el negocio (poco valor) y había otras, de resolución nada clara, había que trabajarselas más, pero que eran las realmente importantes para el futuro negocio que soportaría la aplicación (valor alto para negocio), ahí estaba la “chicha”.
¿Y qué hace el equipo técnico? Sin malicia aparente y ni conscientemente, de manera instintiva, coloca en lo que sería el “product backlog” primero las fáciles y va dejando para abajo las difíciles, para “más adelante” las de mayor valor.
¿Por qué? Por miedo. Miedo a no poder ir dándole desde el principio cosas al usuario. Como el que va echándole filetes a un león para que no se lo coma… hasta que se gastan los filetes. El equipo intenta sacar una versión funcional rápida, con olor a MVP pero sin serlo. Ordenando el backlog por rapidez y facilidad en vez de por verdadero valor, dejando lo más “difícil” para más adelante, para ir dándole cosas al cliente y que no se queje…
Pero… ¿Qué pasará cuando haya que entrar en la verdadera funcionalidad? ¿Y si no se puede hacer lo que el usuario quería? Cada vez la cosa se pone más complicada, ya se ha gastado mucho tiempo en el proyecto como para pararlo, la cosa se pone tensa. Cada vez es más difícil contar la verdad, cómo explicar que en este punto, meses después, no hemos aportado realmente nada de verdadero valor y que quizá no podamos hacerlo.
Tengo una teoría nada contrastada, pero con su sentido común, de que muchas veces actuamos así porque nos han enseñado a no fracasar, que el “fracaso” (entre comillas) es malo, miedo a hacer algo que no sirva, haciéndonos olvidar que se puede aprender mucho del fracaso, más aún si ese fracaso es pronto, controlable y lo más pequeño posible (todo lo contrario de dejar lo valioso, que muchas veces es lo difícil, para el final).
Quizá por ello te encuentras gente que se sabe muy bien la teoría del MVP, de los ciclos de vida ágiles, de priorizar por valor, etc., pero a los que a la hora de la verdad les vence el miedo de decirle cuanto antes a un usuario… esto no se puede hacer o no se puede hacer como tu quieres y, en este punto, antes de gastar más tiempo, aprendamos de ello para lograr un siguiente incremento de valor o dejémoslo aquí y no perdamos más tiempo.

6 comentarios en “Lo difícil de interiorizar el fracaso como buena práctica”

  1. Hola,
    Es difícil ser asertivo con el cliente. Elegir el momento y la forma no es baladí, hay que tener en cuenta muchos factores. A la larga el no saber decir “No” trae problemas, y además la confianza entre el usuario y el equipo siempre sale perjudicada.
    Por otro lado me ha chocado que el equipo priorice el Product Backlog postergando las “necesidades” con más valor. ¿Dónde estaba el Scrum Master? ¿Y el Product Owner?
    Un saludo y gracias por el post

  2. Muy bueno el articulo. Justo voy a empezar un proyecto y estaba apuntando iniciar con los requerimientos fáciles. Replantearé el proyecto.
    Gracias.

  3. Quizá tenga también algo que ver con la «ley de la trivialidad», es decir, que cuando un grupo de gente tiene que tomar una decisión difícil, complicada y que requiere de cierto conocimiento específico, dicho grupo suele perder un tiempo proporcionalmente mayor en decidir primero cuestiones accesorias y triviales, pero en las que todos pueden aportar puesto que no requieren conocimientos específicos, que en lo verdaderamente importante.

  4. En general muy de acuerdo con el planteamiento de Javier. Pero ojo, una aclaración importante que Javier vislumbra pero que tenemos que dejar muy clara: No se trata únicamente de hacer antes lo fácil que lo difícil. El punto está en implementar primero las historias que aportan valor antes que las que no lo aportan. Y luego ya, dentro de las que aportan valor similar, es preferible implementar antes las de mayor riesgo. Mike Cohn lo deja claro en su Agile Estimating and Planning, donde presenta el siguiente cuadro de priorización: http://foldingburritos.com/wp-content/uploads/2015/11/value-vs-risk.png

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba