10 tips para lograr una adopción ágil exitosa

Por Carolina Gorosito [ acerca del autor ]

La gente no adopta una metodología, la adaptan. Tom Demarco

Cambiar la cultura de la organización e incorporar las nuevas prácticas son los mayores desafíos a los que se enfrentan los equipos al intentar adoptar agile, según la encuesta de Scott Ambler.

Todo crecimiento implica una transformación y un proceso de cambio que lleva tiempo. Lo primero que se necesita evolucionar es la forma de pensar para incorporar como hábito la mentalidad ágil con sus prácticas, encontrar los patrones de funcionamiento y edificar alrededor de ellos.

Ahora, por el sólo hecho de incorporar las prácticas, sin una visión organizacional no hará que la empresa sea ágil. Es muy probable que necesitemos el apoyo en varios frentes para reducir el riesgo de dejar cabos sueltos.

Más adelante comentaré algunos patrones de adopción que resultan útiles a la hora de encarar una transformación. Mientras tanto, dejo 10 puntos a tener en cuenta para quienes están pensando en realizar una adopción ágil y no saben por dónde empezar, o han encontrado trabas en el camino.

10 tips para una transformación ágil exitosa

Usar un tablero físico: Insisto en los beneficios de un tablero físico: visibilidad instantánea, acelera la comunicación, es fácil de modificar y da una idea rápida y compartida para todos sobre el estado actual. Además, el equipo puede diseñar su propio tablero, a su gusto, y como parte de un ejercicio de team building. Aún si no están en el mismo lugar, cada individuo puede tener su tablero personal a la vista.

Definir el propósito de la adopción: ¿Para qué queremos adoptar agile? ¿Qué problemas queremos solucionar? No es igual la prioridad de las estrategias de adopción que implementaremos para mejorar la calidad, que para minimizar costos, o hacer entregas más frecuentes.

Tomar métricas: ¿Qué necesitamos medir? ¿En qué usamos el tiempo? ¿Respetamos los time-boxes? ¿Hubo reuniones extra, por qué motivo? ¿Cuántos defectos encontramos; cuánto tiempo nos llevó corregirlos y probarlos? ¿Cuántos impedimentos tuvimos y cuánto demoramos para solucionarlos? ¿Cuánto avanzamos con respecto a lo planificado para la sprint, release, épica, story, tarea? ¿Cuántos bugs se encuentran y arreglan por iteración? Esto nos ayudará a determinar cuáles son las métricas que utilizaremos para el conteo de tareas, defectos, reuniones extra, impedimentos, avance. Podemos utilizar gráficos como Burn up y Burn down para observar el esfuerzo realizado y faltante durante la iteración; velocity para pronosticar la cantidad aproximada de trabajo que podremos realizar a futuro; defectos encontrados y componentes críticos.

Involucrar a un coach: Podemos requerir ayuda a distintos niveles: estrategia de negocio de la compañía, procesos y productos, técnico enfocado al código y pruebas. Estos coaches pueden pertenecer ya a nuestra organización, o podemos contratar a un externo. La ventaja de contratar a un coach es su visión imparcial respecto a los hechos, observa, facilita, capacita, da feedback, sugiere y mentorea durante la adopción.

Menos palabras, más acción: A no detenerse demasiado en las preguntas: ¿Kanban o Scrum? ¿Vamos haciendo un plan o esperamos a contratar a un equipo de desarrolladores?… Hagamos una lista de problemas y prioricémoslos de mayor a menor en impacto negativo (del peor al menos urgente). Hacer un breve diagnóstico del primer problema y tomar una acción de mejora. Ya podremos ir definiendo nuestro camino a medida que avanzamos y corregimos. Recordemos que el agilismo se basa en disciplina, exploración y empirismo. Si nos quedamos esperando todas las respuestas nunca vamos a aprender.

No cambiar lo que funciona bien: Muchas veces en el entusiasmo por la transformación decidimos modificar procesos que cumplen bien su función. Podemos autoimponernos una regla: si funciona, dejarlo como está y enfocarnos en arreglar el siguiente problema de la lista priorizada.

Motivar y convencer: Con convencer me refiero a demostrar los beneficios de las prácticas, no imponerlas. No podemos obligar a los equipos a adoptar agile, el cambio se toma y acomoda de acuerdo a las necesidades. Si ven que les funciona lo aceptarán e incorporarán a su trabajo diario. Tenemos que darles apoyo para que se sientan a gusto, tengan libertad de explorar soluciones y las hagan crecer.

Atender la parte técnica: Además de preocuparnos por las personas, que estén cómodas con el cambio y las nuevas prácticas, debemos verificar el nivel técnico. ¿El código tiene la calidad adecuada? ¿Cómo impactan los bugs y de qué manera? ¿Se quejan los clientes por el bajo rendimiento? ¿Estamos generando deuda técnica? ¿Se terminan (incluyendo las pruebas) las stories para las iteraciones a tiempo? ¿Qué prácticas específicas podemos incorporar para mejorar el código y las pruebas? ¿En qué componentes se concentran más bugs? ¿Cómo trabajan los individuos del equipo en la comunicación durante el desarrollo y resolución de defectos? ¿Cuál es el proceso de desarrollo, utilizamos pair programming, revisiones de código interna, unit testing? ¿Cuál es el ciclo de testing, hacemos revisiones de los tests, smokes, regresiones, automation? Esto requiere de conversaciones entre todos los involucrados. En agile tomamos el principio de software artesanal, sabemos que cada proyecto es único, una obra de arte, por eso prestamos especial atención a la calidad.

Especificar el flujo de entregas frecuentes: ¿Cómo está la comunicación con el cliente, analistas y managers? ¿Hacemos entregas frecuentes de calidad? ¿Entendemos los requerimientos? ¿Planificamos historias regurlarmente para las iteraciones? ¿Tenemos un flujo de trabajo definido y programado? ¿El Product Owner participa en las demos con el equipo? ¿Tenemos métricas de los últimos releases? ¿Cómo medimos la satisfacción de nuestro cliente?

Modificar algunas estructuras: El mismo proceso de cambio generará alteraciones estructurales en la organización y su cultura, las responsabilidades se comparten entre todos y se forman equipos centrados en productos, funcionales, multidisciplinarios e interactivos. Cuando el cambio comienza, todo evoluciona a su alrededor.

Resumiendo, lo importante al plantearse una adopción ágil es saber que llevará tiempo, hay que hacer las preguntas correctas y priorizar las acciones de mejoras.

Temas relacionados:
Certificación PMP® en Administración de Proyectos
Curso breve intensivo de certificación en administración de proyectos para principiantes (CAPM®)