De agilidad se dice y mucho. Pero, ¿qué es cierto? como saber si una cosa funciona o se hace como dicen o es todo lo contrario. Aquí una mirada a los 5 mitos más comunes que suelen existir sobre agilidad y nuestra rápida respuesta a ellos, todo desde nuestra experiencia de lo que vivimos en el día a día desde las trincheras.
Mito 1: «Agilidad es mejor o peor que Cascada (Waterfall)»
En agilidad creemos firmemente que no existe una «bala de plata» (solución para todo), no tenemos razones para afirmar que un enfoque agile aplica en todos los contextos. El enfoque en cascada encaja bien en ambientes de predictibilidad donde los requerimientos están claros y estables desde el inicio y si no se requiere mucha retroalimentación o adaptación durante el proceso.
Por el contrario, si tenemos incertidumbre, si conocemos que es probable que las necesidades cambien y requerimos mucha retroalimentación, un enfoque ágil sería más beneficioso. Es decir, si queremos empezar a desarrollar un proyecto/producto en donde al inicio conocemos lo básico que queremos de él, entonces, empezamos a desarrollarlo con eso y vamos descubriendo, agregando, corrigiendo y entregando valor en el camino.
Fallaremos más rápido (gracias a la transparencia y visibilidad que se obtiene), dejaremos que el equipo de desarrollo del producto y el cliente trabajen juntos, les daremos lo que necesitan y los dejaremos hacer lo que mejor hacen. No es mejor, es lo que se necesita.
Mito 2: «En agilidad son indisciplinados»
En agilidad se promueve la auto-organización y esto no es hacer lo que se nos da la gana. La auto-organización, usualmente se confunde con un entorno caótico y en algunos casos anárquico. Existe metodologías y marcos de trabajo maduros en agilidad que requieren alto grado de disciplina. Scrum por ejemplo, tiene un proceso claro con eventos (ceremonias) que se deben seguir para obtener los resultados esperados. Sin embargo, se cuenta con libertad para auto-organizarnos en la forma que consideremos para obtener nuestros objetivos.
Contrario al mito, en agilidad se requiere mucha disciplina. Para el caso de desarrollo de software se requiere disciplina para hacer pruebas durante todo el proceso de desarrollo, obtener retro-alimentación constante, entregar regularmente, mantener actualizado el plan, levantar los impedimentos que surgen, entre otros.
Mito 3: «En agilidad no se documenta»
La verdad es que en contextos ágiles se documenta, tal vez un poco menos, igual o más que tradicionalmente. La diferencia radica en que la documentación es la justa y necesaria para empezar a producir valor. Todos tenemos claro que el primer objetivo es entregar temprano, así que de primera impresión se comienza a trabajar con la información que esté disponible y en base a las retroalimentaciones y los ciclos cortos las necesidades o historias de usuarios y detalles, la documentación es constantemente actualizada.
En agilidad el reto el reto es mantener los cambios siempre actualizados y esto implica la documentación.
Mito 4: «En agilidad no se planifica»
Aquí diremos rotundamente: ¡falso! A decir verdad si se planifica y mucho más que en waterfall. La diferencia radica en que el planeamiento no es totalmente up-front (por adelantado). Se divide el planeamiento en pequeñas partes del proceso pudiendo identificar la acción de planeamiento en la reunión diaria, el sprint planning, el release planning, entre otras. Lo que sí podemos decir es que es anti-plan.
«El plan es poco importante pero planificar es esencial» decía Winston Churchill. En contextos ágiles la acción de planificar, la interacción al hacerlo cobra más importancia que tener un plan.
Mito 5: «En agilidad hay retrabajo»
Este mito lo he escuchado en varias oportunidades que he dictado algún curso luego de explicarse que en las iteraciones se entrega software potencialmente entregable. La verdad es que si hay retrabajo pero lo aceptamos como tal. Antes solíamos negarnos que habría retrabajo y terminamos pasando ese retrabajo a la parte final que era el testing o pruebas. Aquí existe un balance que debemos tener en cuenta, la agilidad vive con la tensión de entregar tempranamente y no puede esperar que los requerimientos o necesidades estén congeladas por eso en un punto debe tomar la decisión de entregar y luego evaluar cambiar parcial o totalmente lo entregado.
Un ejemplo interesante es el que en industrias como los diarios o las publicaciones de las películas también tienen la presión de entregar el producto de valor por lo que no sería raro que manejan varias versiones del mismo diario o de una película.
Si tienes preguntas cómo: ¿Qué es agilidad y por qué todos están hablando de eso? ¿Por qué yo (jefe/líder/analista/ejecutivo…) debo saber de agilidad? ¿Quienes hacen agilidad?… y sobre todo, si buscas respuestas a estas y otras preguntas, te esperamos en Agile Fundamentals, dale clic aquí y entérate de todos los detalles. ¡Nos vemos el 26!
Saludos.
Gustavo Veliz y Johana Chuquino
Gustavo Veliz y Johana Chuquino
Muy buen artículo. Suscribo los puntos tratados y me ha tocaco vivir muchos. Si me gustaría enfatizar la diferencia entre el Agile Mindset versus las metodologías ágiles. El mindset lo puedes emplear en todas las situaciones incluyendo la vida misma. Las metodologías a usar dependeran de la situación, objetivo y madurez. Parte de la confusión o «ruido» en torno a la agilidad hoy en día es en parte a que una o dos palabras se usan para referirse a muchas cosas.
Gracias por compartir y quedo atento al siguiente artículo.
Jose
Muy buen articulo Johana, sin embargo, quisiera indicar que debemos de quitar la palabra «fallar» en el comentario posteado acerca de «Fallaremos mas rapido» en el contexto agil y utilizar otras palabras mas positivas; ello apoyara al equipo Scrum a motivarse y mejorar su trabajo en vez de sentir culpa por estar fallando en su trabajo, además transmitira una mejor idea u confianza al cliente y los interesados.
«Un buenScrum Masters ayuda a los equipos a ajustar su forma de pensar para que reconozcan los sprints y las características que no alcanzan las expectativas como intentos en lugar de fracasos» Mike Cohn.
Salu2.
Gracias Marco. Comparto el pensamiento de Mike sobre el Scrum Master, en lo que no estoy de acuerdo es en el significado que le damos a la palabra «Fallar» o «Fracasar». Para mi, estas dos palabras formarán parte de nuestras vidas y son tan naturales como el éxito. Creo que más bien por el miedo a fracasar es que se dejan muchas ideas en la mente, no nos arriesgamos a decir algo lo que pensamos por ese miedo a fallar. Y es por eso, que los equipos no logran alcanzar lo que desean. Fallar no es malo (realmente nada es malo o bueno, pero, esa es una conversación de otro tema), siempre que esté en un ambiente controlado, en donde aprendamos de ello.
Saludos