En los últimos eventos ágiles a los que he asistido he vuelto a ver un comportamiento, que ya viene de lejos, que me parece, cuanto menos, poco «mindset» ágil, más aun dándose entre personas que práctica agilidad. Un comportamiento que no puedo decir que yo mismo no haya tenido, un comportamiento que desde hace ya un tiempo yo intento incisivamente evitar y que quiero compartir contigo, por si también compartes esta idea, para que también intentes evitarlo: criticar los errores que en el pasado haya podido cometer alguien que, además, aprendió de ellos y ahora ha evolucionado en base a ese aprendizaje.
En uno de estos eventos, una chica se me acercó y me pidió consejo sobre cómo podía plantearle a su equipo la idea de usar el Punto Historia como «tiempo ideal» en vez de «complejidad», su mayor preocupación era que si lo hacía tendría que hacer explícito que quizá, en su día, haber propuesto el Punto Historia como «complejidad» no fue la mejor idea y tenía miedo a reconocer ante su equipo ese error. No entro en si usar el Punto Historia como «complejidad» es un error (que no tiene porque serlo) lo que me preocupa es la aversión al error, al cambio, a probar cosas nuevas.
En eventos, conferencias, Tweets, etc., hablamos muy fácilmente del «safety», de llevar a los equipos a una zona de seguridad, de permitir el error (controlado y del que se aprende), del Anzeneering, de que una gestión ágil es probar, ajustar, aprender, bienvenido el cambio, etc., pero… luego, en el mundo real, si alguien cometió un error en el pasado, aun habiendo aprendido del mismo, habiendo cambiado, mucha gente «ágil» parece no perdonárselo. Y ese comportamiento no parece muy ágil.
Recuerdo un «debate» en Twitter entre Jeffries y Cohn sobre los puntos historia (no encuentro el hilo de Tweets), pero después de intercambiar varios Tweets con críticas, Cohn le recordó a Jeffries algo que había escrito en uno de sus libros y que era contrario a lo que ahora defendía, entonces Jeffries le citó la primera frase del Manifiesto Ágil: We are uncovering better ways of developing (estamos descubriendo formas mejores de desarrollar).
El mismo Ron Jeffries (firmante del manifiesto ágil) no se ha cortado en reconocer sus errores (como puedes ver en la anterior foto que tome en uno de los Agile de EEUU). Para muchos grandes nombres en agilidad reconocer el error no es que no sea malo… es hasta admirable. Sin embargo, en nuestro entorno más cercano, el error de otro… es un arma a usar en su contra.
Y, en relación a esto… ¿quién no ha cometido un error? ¿quién no ha hecho uso en el pasado de una práctica que hoy no utilizaría? Muchos hemos hecho muchos Gantts (yo hice muchos y los pongo en mis presentaciones como contra-ejemplo) y ahora renegamos de ello (pero los hicimos), muchos hemos hecho muchos UML (yo), quién no ha documentado requisitos (yo lo hice), quién no trabajado en un Cascada (yo lo hice), quién no ha documentado casos de prueba (yo), etc.
No estoy hablando de criticar la manera de pensar de aquellos que aún defienden el uso del Cascada, de la Gestión de Proyectos clásica, etc., que, sin acritud, hasta cierto punto es razonable. No, aquí me estoy refiriendo a criticar, echar en cara, que alguien en el pasado usara algo que hoy consideremos mala práctica, que ya no la use, y que su «error» del pasado (habría que ver si eso, en aquel momento, era un error, pero bueno) sea motivo para criticarle (en vez de alabar que conoció al Lado Oscuro y salió de él). A mí, esto, me parece un pensamiento poco ágil.
Es más, haber estado en el Lado Oscuro, y haber salido de él, a mí me parece un valor añadido. ¿Quién no ha tenido su Lado Oscuro? ¿Quién no ha usado alguna práctica que hoy consideramos errónea, no ágil? Si eres de los elegidos que nunca ha cometido un error ágil, eres un ágil puro de nacimiento, un agilista inmaculado, déjame, cuanto menos… que desconfíe, y en cualquier caso, me quedo con aquellos que pasaron por el Lado Oscuro y salieron de él, porque estos si que saben aplicar agilidad y por qué.
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.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Hola Javier, que tal, ¿es mala práctica documentar los casos de prueba?