¿Qué puede salir mal al seguir la metodología ágil en 2023?

Introducción

Si hablas con desarrolladores o gerentes en tu red, la mayoría de ellos te dirán que sus equipos están usando la Metodología Ágil. 

La mayoría de las ofertas de trabajo que verás tendrán el término Proceso ágil mencionado en alguna parte de su descripción de trabajo. 

Así que creo que es justo decir que el término Proceso ágil está de moda hoy en día en la industria del software, y usar Proceso ágil en tu equipo es tan bueno como usar IA/ML en tu código. 

Si tu respuesta es sí, entonces ahí es donde comienza el problema. Cuando algo es genial, la gente quiere adoptarlo lo más rápido posible. Como sabemos, muchas empresas que afirman que están usando algoritmos geniales de ML/AI en su código solo están usando declaraciones if-else en segundo plano. Lo mismo está sucediendo con Agile también. De todos los equipos que afirman seguir el proceso Agile están lo suficientemente lejos del proceso y simplemente atrapados en un lugar donde no obtienen ninguna ventaja de Agile.

Requisito previo

Este artículo es útil para ti si comprendes la Metodología ágil y tu equipo ya está utilizando Procesos ágiles.

Razones por las que el proceso ágil podría no estar dándote los resultados esperados

Analicemos algunos errores que cometen las empresas y los equipos al seguir la Metodología ágil. Si tu respuesta a cualquiera de las siguientes preguntas es sí, entonces es el momento en que necesitas trabajar para mejorar el proceso ágil que se sigue en tu equipo.

¿Estás saltando al paso de implementación sin darle mucha importancia a las fases de SDLC antes de eso?

Tener pequeñas iteraciones y lanzar cambios a los clientes es uno de los puntos clave de Agile. Esto proporciona un gran beneficio de la retroalimentación rápida de los clientes, de modo que, si hay alguna brecha entre la expectativa y el resultado, se puede identificar en una etapa temprana. 

Sin embargo, a veces los equipos malinterpretan esto y piensan que, dado que tienen la influencia para obtener comentarios rápidamente, deberían comenzar a trabajar en la implementación sin poner mucho esfuerzo en las fases de recopilación, análisis y diseño de requisitos.

Esto resulta en un desastre cuando con el tiempo el proyecto se vuelve inmanejable y nadie tiene una idea de lo que hay que hacer, cuánto trabajo queda pendiente y cuánto se ha completado.

Sugerencias para mejorar:

La regla SDLC para Agile es:

• Una Épica debe tener un documento de requisitos claramente definido,
• A excepción de Spike y POC, todas las demás historias de usuario deben estar respaldadas por un documento de diseño.
• El DOD de las historias de usuarios debe lograr claramente uno u otro objetivo de un documento de diseño o un documento de requisitos.

¿Decide el responsable de las tareas y los puntos de la historia de esa tarea?

Aunque puede parecer algo muy pequeño, no estandarizar los puntos de la historia puede afectar no solo los plazos de entrega de tu proyecto, sino que también puede dañar la cultura de trabajo de tu equipo hasta la médula.

Muchos equipos creen que el propietario de la tarea conoce los esfuerzos necesarios para completar la tarea, por lo que es la persona adecuada para asignar puntos de historia a la tarea. Aunque esto parece correcto a primera vista, también causa problemas. Entendamos esto con algunos de ellos.

• Como los puntos de la historia asignados por una persona no funcionarían para otra, tales asignaciones crearían un alto acoplamiento entre la tarea y el asignador del punto.
• Puede haber escenarios en los que la persona A puede realizar una tarea en un día, pero la persona B necesitaría 5 días para completar esa tarea. Entonces, el desempeño de la persona A es 5 veces mayor que el de la persona B. Pero si ambos tienen la libertad de asignar puntos de historia para la tarea que están haciendo, entonces la persona B asignará 5 veces más puntos de historia que la persona A, y si no se realiza un escrutinio, nunca podrá encontrar la diferencia de desempeño entre la persona A y B.
• La finalización del proyecto dependería demasiado de quién está manejando el proyecto que cuál es la complejidad del proyecto.

Sugerencias para mejorar:

• La asignación de puntos de historia no es una tarea individual. Es una actividad de grupo.
• La mejor manera es involucrar a todo el equipo (o al menos a los miembros clave del equipo) y pedirles que proporcionen la estimación puntual.
• Después de obtener los puntos estimados, un equipo puede optar por tomar el máximo, el mínimo o el promedio de todas las estimaciones.

¿Crees que monitorear de cerca la creación y el cierre de historias/tareas es una pérdida de tiempo?

Si los product owner y los gerentes de ingeniería no están monitoreando las nuevas tareas agregadas a Épicas, entonces puede conducir al caos y al progreso sin dirección de Épica. Si las historias no tienen una definición adecuada de hecho (DOD), entonces contribuirán solo a ocultar la ineficiencia del equipo. 

Comprendamos las razones por las que debe tener un seguimiento en la creación y cierre de historias.

• No todos en el equipo tendrían el mismo nivel de comprensión de Épica y las historias no analizadas pueden no tener el contexto correcto, la conexión con otras historias y una definición significativa de hecho. Tales historias no contribuirían más que a la confusión en el momento de la preparación del retraso en la evaluación del estado de Épica.
• Si varias personas están creando las historias en una epopeya sin coordinación, existe la posibilidad de que las historias se creen con DOD duplicados o superpuestos. Esto resultará en esfuerzos duplicados por parte de los miembros del equipo.
• Aunque en un mundo ideal creemos en las mejores intenciones y pensamos que todos quieren trabajar para el éxito del equipo y del proyecto, aceptemos esto con una pizca de sal de que no todos en su equipo estarían igualmente motivados. No es raro encontrar historias creadas intencionalmente que no tienen DOD claro o DOD duplicado. Tales historias se usarían para marcar los esfuerzos en un sprint sin poner mucho esfuerzo en ellos.

Sugerencias para mejorar:

• Todas las historias que se crean y cierran deben ser revisadas por el gerente de ingeniería o el propietario del producto del equipo.

¿Crees que las retrospectivas de Sprint son innecesarias?

Las reuniones retrospectivas son importantes para el proceso Agile como lo son los chequeos de salud para nosotros. Estos son como chequeos de salud. Si va a someterse a chequeos médicos regulares, podrá identificar comportamientos anormales en el cuerpo en una etapa muy temprana y vivir una vida saludable. Del mismo modo, si su equipo se toma en serio las reuniones retrospectivas, podrá encontrar cualquier anomalía en el proceso ágil en una etapa temprana.

Si la respuesta a cualquiera de las siguientes preguntas es afirmativa, puede considerar que no está utilizando estas reuniones de manera eficiente:

• Si alguna historia no se completa en un sprint, entonces, en lugar de discutir las razones en detalle, ¿su equipo simplemente pasa eso al siguiente sprint o en la cartera de pedidos?
• Si DOD no se completa para ninguna historia, ¿simplemente cierra esa historia para marcar los esfuerzos y abre una historia duplicada para el próximo sprint?
• ¿No revisa cada historia y compara los puntos asignados a las historias y el esfuerzo real invertido en las historias?

Sugerencias para mejorar:

Los siguientes puntos tienen que ser cubiertos en las reuniones retrospectivas.

• Analice cuántas historias requirieron más o menos esfuerzo que el esfuerzo estimado y por qué sucedió eso. Esto ayuda a corregir las estimaciones de esfuerzo en futuros sprints.
• Si hay historias incompletas, analice la razón detrás de eso. Por ejemplo, los retrasos debidos a otros equipos, el DOD poco claro y los cambios desconocidos surgen durante la implementación de los cambios. Esto ayuda a identificar qué fase anterior (recopilación de requisitos, diseño, etc.) necesita mejoras.
• Si hay historias en las que se ha puesto algo de esfuerzo, pero la historia aún no se ha completado, cambie el DOD y cree otro ticket con un DOD incompleto. Esta acción debería haberse tomado solo después de recibir el aviso de los miembros del equipo, incluidos el Gerente de ingeniería y el Propietario del producto.

Conclusión

He tratado de cubrir las razones principales por las que seguir Metodología Ágil resulta en una disminución de la eficiencia del equipo y brindé sugerencias para mejorarlas. 

Si su equipo no está cometiendo ninguno de estos errores, felicidades, está utilizando el proceso ágil de la manera en que se espera que se utilice. Si hay algún punto que cree que su equipo no está siguiendo, intente seguir las sugerencias proporcionadas para mejorar en esa área. Estoy seguro de que te encantarán los resultados.

Es cierto que crear un buen diseño UX puede ser desafiante y confuso en un principio, pero para eso estamos, para ayudar. Contacta hoy para programar tu sesión de estrategia y dejar que comience la lluvia de ideas.