Recuperando Agilidad a través de Kanban

El problema observado

A lo largo de los años,  hemos visto cómo los equipos que implementan Gestión Ágil logran un cambio positivo en su trabajo, generando valor de forma más rápida y periódica. Sin embargo, en el caso de los equipos que ya han estado activos durante un tiempo,  esto no suele perdurar.
He aquí algunas de las razones:

La gestión ágil clásica establece que el equipo de desarrollo se relaciona con un único “Product Owner”, que al comienzo del Sprint negocia la cantidad y prioridad de las Historias de Usuario (HdU) que serán implementadas. Ver Figura 1.

Otra regla es que durante el sprint el alcance no será modificado [1], lo cual ayuda al equipo a mantenerse enfocado. Ver Figura 2.

En la realidad de un equipo que posee cierta historia (y deuda técnica acumulada) hay situaciones que cuestionan estas reglas: hay otros proyectos que requieren soporte, nuevos negocios que necesitan consultoría técnica, etc.  Es decir, surgen múltiples imprevistos que “interrumpen” al equipo durante el Sprint, haciendo imposible “proteger” al equipo de cambios, lo que sumado a múltiples focos de atención desmoronan el orden logrado. Ver Figura 3.

Debido a lo anterior, la disciplina lograda por la agilidad se comienza a perder, regresando al caos inicial. Es aquí donde podemos aplicar los principios de Kanban para transformar ese proceso caótico de vuelta a un modelo ágil.

Visualizando el flujo

Lo primero es visualizar el flujo de trabajo tal cual lo están ejecutando ahora. Parafraseando el chiste que dice que “la diferencia entre Software y Hardware es que al primero sólo lo puedes maldecir”, si el flujo de trabajo no es visible, lo único que se puede presionar es a las personas del equipo de trabajo. Por ello se establece el modelo de “empuje” (PUSH), causa de cuellos de botella y de pérdida de foco debido a los cambios de contexto. Ver Figura 4.

Al “vaciar las cabezas” en un tablero que modela el flujo de trabajo actual, ahora todos adquirirán un entendimiento compartido de la realidad del proyecto y las conversaciones en vez de enfocarse en un individuo, ahora sucederán sobre dicho tablero. Los problemas comienzan a ser evidentes y el trabajo comienza a verse como responsabilidad de todos y no de una persona específica, incluso cuando hay especialidades de por medio. Es así que ahora la atención de todos se puede enfocar en el flujo de trabajo, más que en presionar a las personas. Ver Figura 5.

Figura 1. El Cliente negocia y prioriza las HdU para el Sprint.

(Re)estableciendo la cadencia del trabajo y la disciplina asociada

El segundo paso será (re)establecer la disciplina de gestión y la cadencia del trabajo. En nuestra experiencia la mejor forma de realizar esto es a través de reuniones de pie periódicas en torno al tablero. En ellas se van revisando los ítems(elementos) de trabajo del tablero, desde los que están a punto de terminar hasta los menos avanzados, siguiendo el mantra “Para de comenzar, comienza a terminar”. Las preguntas que hemos ido desarrollando con los equipos que apoyamos [2] en las reuniones frente al tablero son:

1. ¿Quién es responsable de este ítem? Es importante considerar que el responsable de un ítem es quien se ofreció a velar la ejecución del trabajo asociado a este desde que llega hasta que se entrega. Puede perfectamente haber otros involucrados técnicamente en el desarrollo de éste.
2. ¿Cuánto se ha avanzado en este ítem desde la reunión de pie pasada?
3. ¿Cuándo estimas que pasará al siguiente estado del flujo? ¿Tienes algún impedimento?
4. ¿Qué has aprendido gracias a este ítem?

La última pregunta puede parecer innecesaria, pero en nuestra experiencia permite que aparezcan descubrimientos que muchas veces se dejan de lado y que deberían guardarse en el wiki del proyecto. También es importante hacer notar que si se declaran impedimentos, estos deben ser abordados en una reunión posterior con las personas más idóneas para resolverlo.

Queda pendiente la pregunta de cuándo es el momento en que una persona debe asumir la responsabilidad de un ítem. Aquí es donde aparece el modelo de arrastre (PULL) que establece que una persona que termina un ítem pasa a escoger del tablero aquello que aparezca más prioritario, que en general será aquello más cerca de terminar.

Figura 2. Durante el Sprint/iteración, no se aceptan cambios de alcance.

Limitando el trabajo en curso

Uno de los principios más poderosos de Kanban es limitar el trabajo a medio hacer (WIP- Work in Progress). En el modelo tradicional deScrum esto se hace de forma implícita al establecer un alcance fijo en el Sprint. En Kanban se le pide al equipo definir un límite de ítems por estado (columna en el tablero), priorizando mover los ítems al próximo estado antes de arrastrar un nuevo compromiso del estado anterior.  Una forma de potenciar el foco es que cada persona en la reunión de pie ponga un post-it con su nombre sobre el ítem en el que trabajará ese día, incluso si tiene otros temas abiertos. Esto ayuda a transparentar los compromisos y enfocar la energía.

Figura 3. Múltiples fuentes de requerimientos confunden al equipo.

Lidiando con múltiples interrupciones de varias fuentes de requerimientos

Ya que nos hemos dado cuenta de que es un hecho que el equipo recibirá nuevos requerimientos a lo largo del proyecto, al igual que el slogan del libro “Extreme Programming Explained” de Kent Beck “abrazaremos el cambio”, utilizando un modelo de planificación “justo a tiempo”: aquellos requerimientos que tengan prioridad regular, deberán colocarse a la cola de los que ya fueron planeados. Los de mayor urgencia  podrán ponerse primero en la cola de salida, o incluso bloquear de forma explícita un ítem en curso (marcándolo de forma visible en el tablero) para darle paso a la emergencia. Así todos tomarán conciencia del impacto provocado por el intercambio de prioridades. Los distintos tipos de prioridades se denominan “clases de servicio”, y poseen sendas políticas de gestión conocidas por todo el equipo.
Si los múltiples demandantes están compitiendo por quien logra más dedicación del equipo, es importante establecer una mesa de negociación periódica con ellos para establecer criterios en común y uso racional de la capacidad demostrada en el tablero.

Figura 4. Si lo que está pasando sólo está en las cabezas de los desarrolladores, entonces serán permanentemente interrumpidos.

Figura 5. Entendimiento compartido del estado actual del proyecto.

Conclusiones

El modelo que hemos descrito ha logrado que decenas de equipos se recuperen del caos luego de una implementación ágil fallida, mejorando la moral y recuperando la capacidad de aprender característica de la agilidad.  El proceso que se irá logrando probablemente no será una implementación exacta de la gestión ágil tradicional, sino que será un modelo de gestión “ad hoc” que puede ser enriquecido incrementalmente con prácticas de gestión ágil de Scrum y/o XP. Y gracias a las propiedades transformadoras de Kanban, más resistente frente a las situaciones imprevistas.

Anotaciones
[1] Esta regla fue flexibilizada en la edición más reciente (Octubre 2011) del Scrum Guide, hecho poco conocido en la práctica.
[2] Este modelo modifica las tres preguntas clásicas de Scrum, en donde se va preguntando persona a persona, y está inspirado en http://agile.luminis.nl/?p=65