Como hacer la transición a «Agile»

Cada vez que hay una transición hacia una nueva metodología (hacia un nuevo loquesea), tienes múltiples escenarios. Dentro de la gente implicada en el cambio, hay algunos que lo abrazan y lo lo asumen como ese cambio que realmente se necesitaba. Uno de los problemas con cualquiera de estos cambios es centrarse en lo llamativo, en los «artefactos», y olvidarse del motivo del cambio. En el caso de agile, hay gente que pone más interés en las reuniones diarias o en el color de los post-it que en conseguir que la dinámica fluya y los procesos mejoren.

Este hilo de Allen Holub, me hizo pensar eso. Así que me permito traducirlo por si sirve de ayuda:

¿Cómo se hace la transición a «Agile»? Ten en cuenta que cada organización es diferente, por lo que puede ser que nada de lo que diga a continuación te aplique. Describiré una progresión lineal. Por supuesto, si la organización tiene capacidad para realizar estas tareas en paralelo, siempre será mucho mejor.

A menudo la necesidad crítica es tener el trabajo bajo control, así que comienza con el trabajo de «producto». Aprende cómo hablar con los clientes (e involucra a los clientes en el día a día). Aprender qué son las historias, crearlas y reducirlas, aprender a organizarlas y ordenarlas por valor.

Me gusta presentar los mapas de historias como el principal mecanismo para la gestión de los atrasos. A continuación, puedes pensar en la implementación, comenzando con algunas prácticas sencillas: por ejemplo Test Driving Development (TDD) y mob programmning. Empieza a modificar la estructura organizativa para que el trabajo sea posible.

Deliberadamente no empiezo con reuniones y ceremonias (Scrum o de otro tipo). Eso tiende a poner énfasis en las cosas equivocadas. Inadvertidamente, se puede caer en el error de que las reuniones son suficientes, de que el proceso es más importante que hacer el trabajo.

Una vez que el trabajo esté bajo control, comienza a introducir un proceso que haga más eficiente el desarrollo. Comienza con la retrospectiva y la mejora continua. Me gusta la «kata de mejora» de Mike Rother. La retrospectiva es con mucho la parte más importante de CUALQUIER marco ágil.

Ahora los equipos se encuentran en un lugar donde pueden aplicar inspecciona-y-adapta a sus procesos. Si se quiere evaluar, los «factores de éxito» son: el trabajo está bien estructurado, los equipos trabajan en equipo, la calidad es integral y existe un proceso de mejora continua.

Todo lo demás son adornos.

Actualizado 2019.08.20

Muy relacionado con esto es el artículo de Product Coalition.

¡Que levante la mano quien se sienta identificado con lo que allí se dice!