El enfoque ágil tiene dos objetivos esenciales: mejorar la dinámica de trabajo del equipo favoreciendo su motivación y compromiso, y al mismo tiempo, aumentar la rentabilidad del esfuerzo invertido por el equipo, dirigiéndolo a maximizar la satisfacción del cliente. Todo esto está muy bien, pero ¿cómo llevarlo a la práctica?¿cómo comenzar?. Podríamos pensar que la respuesta es sencilla ya que disponemos de varios métodos ágiles (Kanban, Scrum, Lean Development, Extreme Programming, etc.) y de decenas de herramientas que ofrecen apoyo a dichos métodos. Sin embargo, la implantación del enfoque ágil no es fácil, encierra muchos desafíos, es un proyecto de cambio organizacional. Además, aunque existen métodos ágiles y muchísima literatura al respecto, para bien y para mal no existe una interpretación unificada del enfoque ágil. Por un lado, el enfoque ha tenido libertad para evolucionar rápidamente por no estar regulado por ningún organismo, pero al mismo tiempo la etiqueta "ágil", en muchas implantaciones del enfoque, se ha auto-otorgado muy alegremente :-). Muchas empresas que se han lanzado a implementar el enfoque ágil se han dado cuenta que no basta con asistir a formaciones o certificaciones en agilidad, ni tampoco es suficiente con adquirir una herramienta para conseguir una mejora significativa en el trabajo (incluso es contraproducente comenzar con esto). Si no se dispone de una metodología adaptada al contexto de trabajo las expectativas de mejora no se cumplirán.Por nuestra parte, durante muchos años trabajando con el enfoque ágil hemos ido refinando TUNE-UP Process, una propuesta metodológica que integra las prácticas ágiles de los principales métodos ágiles en un modelo conceptual unificado. TUNE-UP Process es nuestra interpretación de qué es el enfoque ágil, y tiene a su favor la experiencia conseguida trabajando en diversos contextos de empresa, con un enriquecimiento continuo al utilizarse como base para cursos de formación, y con el alineamiento con Worki, su herramienta de apoyo, con lo que hemos llegado a reunir todas las piezas: modelo, metodología y herramienta.
En este post presento lo esencial del modelo conceptual de TUNE-UP Process. Este modelo contribuye a establecer una buena infraestructura para organización ágil del trabajo, lo cual favorece la implantación del enfoque ágil y permite ir adaptándolo a las necesidades del contexto de trabajo.
Modelo conceptual de TUNE-UP Process
La siguiente imagen muestra los principales conceptos incluidos en nuestra propuesta metodológica. Durante el resto del post describiré en detalle cada uno de ellos.
Cada UT desde su creación hasta su término sigue un flujo de trabajo (workflow), que corresponde a una secuencia de Actividades (pudiendo existir actividades realizadas de forma alternativa o en paralelo). Los workflows determinan los Tableros kanban que se utilizarán, en los cuales las actividades de un workflow corresponden de izquierda a derecha con las actividades de un Tablero kanban. Cada Tablero kanban muestra en qué actividad (o estado) están las UT que siguen ese flujo de trabajo. Para el diseño de workflows y tableros kanban recomiendo leer: "Workflows flexibles. Parte I y Parte II" y "Tableros kanban. Parte I y Parte II".
Una Línea de Trabajo es el contenedor global de UT. Podríamos NO reconocer Líneas de Trabajo (es decir, tener solo un contenedor para todo el trabajo) pero hay varios factores que hacen conveniente agrupar el trabajo en diferentes Líneas de Trabajo, entre ellos:
- Planificación y seguimiento del trabajo. Trabajos que normalmente tienen distintos calendarios de compromisos o acuerdos de ritmos de entrega.
- Equipos de trabajo. Trabajos asignados a diferentes equipos de trabajo.
- Distribución de capacidad de los equipos. Trabajos que en un período de tiempo compiten por asignación de Capacidad del equipo. Así, según prioridades, se puede distribuir explícitamente la Capacidad del equipo en sus diferentes Líneas de Trabajo.
Toda Línea de Trabajo tiene un Backlog. El Backlog es el contenedor de las UT que NO se están contenidas en un Sprint, es decir, las UT estarán en el Backlog o en algún Sprint. Cuando se decide NO trabajar con Sprints conceptualmente todas las UT están en el Backlog, allí se priorizarían e irían terminándose. Cuando se trabaja con Sprints, normalmente mientras están en el Backlog a las UT se les aplica un trabajo de "preparación", y al pasar a un Sprint se les aplica el trabajo asociado a su "ejecución". Por ejemplo, actividades típicas de "preparación" en el Backlog son: Priorizar, Definir/Analizar/Especificar, Validar, Estimar, etc. Actividades típicas de "ejecución" en un Sprint son: Programar/Implementar, Probar, Integrar, Desplegar, etc. Así pues, el Backlog y los Sprints en un Tablero kanban se corresponden con grupos de columnas; las del Backlog en la parte izquierda del tablero y las de Sprint en la parte derecha. Si se decide NO trabajar con Sprints en una Línea de Trabajo todas las actividades, tanto de preparación como de ejecución se realizan en el Backlog (todas las columnas del Tablero kanban se realizan estando las UT en el Backlog).
Cuando se adquiere un compromiso de entrega (fechas de inicio y fin) es recomendable enmarcar todas las UT de dicho compromiso (el alcance) en un Proyecto asociado a la Línea de Trabajo. Este compromiso requiere tener establecido un alcance y costos, es decir, estamos en una situación de trabajo "planificable". Usualmente el desarrollo de la primera entrega de un producto/servicio es por definición un Proyecto. Sin embargo, después de la primera entrega, si no vuelven a existir compromisos alcance-plazos-costos, podría continuarse el trabajo asociado al producto/servicio sin tener asociado un Proyecto.
A continuación se responden varias cuestiones claves respecto de la combinación de los elementos del modelo conceptual propuesto. Es importante destacar que estas cuestiones deben evaluarse para cada Línea de Trabajo; uno de los errores más frecuentes es ignorar la diversidad del trabajo e imponer la misma estrategia para todo el trabajo y/o no reconocer diferentes Líneas de Trabajo, cada una con sus necesidades.
¿Tiene sentido usar un Tablero kanban si también se usan Sprints?
Se usen o no Sprints, siempre es necesario utilizar un Tablero kanban para visualizar el estado de preparación y ejecución de las UT.
¿Cuándo conviene usar Sprints en una Línea de Trabajo?
Los Sprints son importantes para ayudar a gestionar el desarrollo incremental a corto plazo. Sin embargo, en situaciones NO planificables (cuando el alcance no se conoce totalmente de antemano o suele variar significativamente) no es sensato imponer una disciplina de Sprint "rígidos" en contenido y/o duración, dado que cualquier previsión probablemente se verá muy afectada por cambios durante el Sprint. En el caso extremo, si gran parte del esfuerzo de planificar Sprints se pierde por los continuos cambios durante el Sprint, podría prescindirse de usar Sprints y trabajar solo con un Backlog priorizado. Sin embargo, los Sprint podrían ser "flexibles" para acomodarse a un cierto nivel de cambios durante el Sprint (ver "Sprints, welcome to the real world ..."), asumiendo cambios en cuanto a contenido y en duración de los Sprints, o que puedan comenzar aún sin tener todas sus UT preparadas, o que puedan existir a la vez más de un Sprint abierto. En su forma "más flexible" y solo con el propósito de consultar trabajo realizado, el contenido de un Sprint podría establecerse a posteriori (sí, después de terminar un conjunto de UT), es decir, aprovechar los Sprint solo como agrupador de trabajo ya terminado, e incluso poniéndole nombres asociados al calendario. Por ejemplo, en un Sprint llamado "2019 Abril", en el cual se ha incluido todo el trabajo terminado durante el mes de abril de dicho año.
¿Tiene sentido usar Proyecto y Sprints en una Línea de Trabajo?
Tanto Proyecto como Sprint son contenedores temporales de trabajo, y lo usual es que el alcance de dicho trabajo esté previsto antes de comenzar a trabajar en ello (y que la estimación de esfuerzo sea coherente con la Capacidad del equipo encargado). Por otra parte, se recomienda que los Sprints NO tengan una duración de más de 4 semanas pues su objetivo es darnos una retroalimentación a corto plazo del avance del trabajo. Sin embargo, un Proyecto no tiene dicha restricción de duración. Así pues, sí que puede ser útil combinar los conceptos de Proyecto y Sprints. Por ejemplo, para un Proyecto de 6 meses se podrían establecer 8 Sprints de 3 semanas cada uno. Las UT del Proyecto estarán priorizadas en el Backlog y se irán incluyendo en los sucesivos Sprints hasta finalizar el Proyecto. Al finalizar el Proyecto podrían quedar algunas UT en el Backlog (ya quitadas del alcance del Proyecto), podría tratarse de algunas UT originales, o de nuevas UT que se hayan generado durante el Proyecto. Esta es otra de las razones del por qué es importante separar el concepto de Proyecto del concepto de Línea de Trabajo; aunque el Proyecto finalice, la Línea de Trabajo asociada al producto/servicio seguirá existiendo y tendrá trabajo asociado que habrá que abordar posteriormente (dentro o fuera del marco de otros Proyectos).
No tiene sentido usar Sprints si la duración del Sprint es igual a la del Proyecto. Por ejemplo, si el Proyecto es de 2 semanas y se establece que se hará solo un Sprint de dos semanas, en este caso el Sprint no aportaría nada respecto de la planificación y seguimiento del trabajo. Puede que tampoco tenga mucho sentido tener Sprints muy pequeños, cuando el Proyecto sea de muy corta duración. Por ejemplo, un Proyecto de 3 semanas dividido en 3 Sprints de una semana. Hay que evaluar los "costos de transacción", es decir, el esfuerzo asociado a arrancar un Sprint y a terminarlo (siguiendo todos los protocolos asociados).
Conclusiones
El modelo conceptual propuesto sirve de infraestructura para organizar el trabajo de forma ágil. Sin embargo, hay que destacar que un enfoque ágil no consiste solo en utilizar conceptos ágiles. El mayor desafío es aplicar prácticas ágiles (hábitos de trabajo), y para esto es fundamental establecer un roadmap para ir incorporando dichos hábitos ágiles en el trabajo diario del equipo. Ver nuestra colección de prácticas ágiles en Agile Roadmap.La libertad que ha tenido el enfoque ágil en cuanto a propuestas e interpretaciones en muchos casos se ha vuelto en su contra. Por ejemplo, el abuso del término Proyecto; si a todo se le llama Proyecto, cuando un proyecto termina ¿hay que crear otro proyecto con el trabajo restante o con el nuevo trabajo que va surgiendo y que está asociado al mismo producto/servicio? ¿hay que cambiarle nombre y fechas al Proyecto una vez terminado terminado para reutilizarlo?. Cuando se solapa para un mismo producto el desarrollo de nuevas funcionalidades con el mantenimiento continuo (de respuesta rápida y con urgencias) ¿se enmarca todo este trabajo en un mismo Proyecto?. Estas confusiones respecto del término Proyectos o la confusa combinación de Tableros kanban con Sprints se ven fomentadas por herramientas como en JIRA o Target Process, donde queda en evidencia la falta de un buen modelo conceptual. En esta temática, recomiendo leer:
"El concepto "Línea de trabajo": más allá de Proyectos, Productos o Servicios"
"Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega"
"Organización ágil del trabajo"
Patricio Letelier
