Aplicando Kanban para Recuperar un Proyecto Caótico

Las prácticas del método Kanban proveen el contexto para que valores como honestidad, comunicación, confianza, respeto y coraje emerjan de manera natural y sin resistencia dentro de un equipo de desarrollo de software. En este caso de estudio se describen situaciones clave durante el proceso de adopción de Kanban en un proyecto de desarrollo de software caótico. Con Kanban el equipo ha aprendido a convivir inmerso en el cambio y en el arte de mantener equipo y cliente satisfecho bajo estas circunstancias.

La situación
El equipo trabajó bajo un esquema típico en cascada donde las tareas se estimaron y asignaron a recursos de acuerdo a un diagrama de Gantt. Según el miembro del equipo más experimentado, trabajar tarde y los fines de semana era una práctica aceptable, sobre todo después de llevar a cabo demostraciones de avances de funcionalidad donde por ejemplo una tarea avanzada al 80% (según el Gantt) podía bajar al 20% debido a cambios solicitados por el cliente y falta oportuna de retroalimentación. La falta de honestidad, confianza y respeto eran evidentes, el equipo no era lo suficientemente honesto para comunicar al cliente el avance real. Para exacerbar la situación, el equipo no definió un criterio para considerar terminado cada requerimiento solicitado. Consecuentemente el cliente había perdido la confianza en la capacidad del equipo para entregar software, este círculo vicioso de deterioro de honestidad y confianza se repitió una y otra vez hasta el punto donde el respeto entre ambas partes se perdió. Fue entonces que me involucré en el proyecto y utilizamos técnicas de Kanban para recuperarlo.

El árbol de alto desempeño
El árbol de alto desempeño es una metáfora acuñada por Lyssa Adkins [1], que es un buen punto de partida para establecer la visión de un equipo de alto desempeño. Asumiendo que estás introduciendo Scrum al equipo, el árbol se dibuja desde las raíces a medida que se van enseñando los valores de Scrum. Para este proyecto utilicé un enfoque distinto acorde con las prácticas de Kanban y una cultura Kaizen. Establecimos que las siguientes prácticas de Kanban serían las raíces cuya adopción nos ayudarían a crear un conjunto de valores inexistentes en el equipo:

• Visualización y transparencia
• Mejora continua
• Entregas frecuentes
• Priorización en base al valor
• Limitar el trabajo a la capacidad del equipo

Si las prácticas arriba (lo que serían las raíces) se ejecutan de forma consistente, gradualmente se harán más fuertes —e inherentes a la cultura— y por lo tanto el árbol se fortalece. Las hojas (valores) brotarán, obtendrán más luz y se volverán verdes alimentando al árbol como un todo. Dependiendo de la situación podrán emerger los valores que necesitamos para lograr el éxito:

• Honestidad: Las malas noticias con prioritarias, nada se esconde al cliente o entre los miembros del equipo
• Comunicación: La información correcta en el momento oportuno con las personas indicadas
• Confianza: El cliente tiene que confiar en la capacidad del equipo para entregar consistentemente
• Respeto: Hacia las contribuciones de cada uno de los miembros del equipo de acuerdo a su background y habilidades. No hacer perder el tiempo de la gente
• Coraje: Para aceptar el cambio y cambiar continuamente, experimentar, aprender, fallar y enseñar a otros

Tenia claro que después de un tiempo los frutos empezarían a brotar. Los resultados estarían directamente relacionados al cambio cultural inspirado por las prácticas de Kanban y los valores continuamente reforzados en un ciclo positivo.
Los frutos buscados eran: predictibilidad, calidad, satisfacción tanto del equipo como del cliente, auto-organización, crecimiento profesional del equipo y sus miembros.
La figura 1 muestra una imagen del árbol de desempeño que generamos, y que a partir de su definición continuamente referenciamos en las retrospectivas.

Figura 1. Árbol de alto desempeño.

Kaikaku
Una vez definida la visión y teniendo en claro los valores que teníamos que recuperar se acordó con el equipo detener inmediatamente el proceso de desarrollo de software. Dentro de los principios de Lean esto significa “stop the line”.
Acordamos enfocar todos nuestros esfuerzos para crear un backlog del producto con el formato de historias de usuario. Con la priorización de las historias se pudo distinguir los ítems funcionales de alto con los de bajo valor necesarios para lanzar la aplicación. Posteriormente definimos políticas por cada una de las fases del proceso de desarrollo actual y las hicimos explícitas.

Cultura Kaizen
La auto-organización empezó a emerger. Siguiendo nuestro objetivo de recuperar la confianza, organizamos sesiones apenas tuvimos algo que mostrar. Para minimizar el costo de coordinación acumulábamos tres historias completas antes de convocar al cliente para llevar a cabo una demo.
Éste fue el punto de partida para construir honestidad y confianza. El equipo empezó a ser lo suficientemente honesto en cuanto a lo que podía entregar de acuerdo a un ritmo de trabajo sostenible. Frecuentemente se invitó al cliente a inspeccionar nuestro tablero de kanban para mantener las conversaciones dentro del contexto. La comunicación entre los miembros del equipo y el cliente comenzaron a mejorar, los primeros signos de coraje comenzaron a emerger, el equipo tenia ya el coraje para pedirle retroalimentación al cliente para clarificar el criterio de aceptación, sabían que las prácticas de Kanban (priorización en base a valor) los protegerían de cambios fuera del ámbito del criterio de aceptación acordado en las historias. La figura 2 muestra los primeras tableros kanban rudimentarios que usamos.

Figura 2. Tablero rudimentario.

Estimar es desperdicio
Antes de asumir el liderazgo del equipo las estimaciones se basaban en especulaciones acorde con un cronograma que nunca se cumplía, por lo tanto estimar era una pérdida de tiempo. Costó trabajo convencer al cliente de dejar de insistir en fechas de entrega y que la mejor forma de predecir el proyecto era a través de entregas continuas. Se acordaron políticas según la definición de terminado para cada cambio de estado de los requerimientos dentro del flujo de valor en Kanban de acuerdo al ciclo de desarrollo de software existente: análisis, diseño y desarrollo, paquete para QA listo, pruebas en entorno de QA, paquete para preproducción listo y pruebas en entorno de pre-producción.

Evolución de un tablero simple hacia uno avanzado
En cierto punto consideramos que la visibilidad que habíamos logrado no era suficiente por lo que decidimos tener un tablero tipo Scrum externo al kanban para gestionar las tareas de programación de las historias en la fase de desarrollo. Si bien Kanban no sugiere la descomposición de las historias a ese nivel nosotros consideramos que este nivel de visibilidad facilitó la auto-organización y el trabajo en equipo. Posteriormente decidimos que este tablero tipo Scrum debía estar embebido dentro del tablero Kanban ante lo cual decidimos incorporarlo evolucionando nuestro tablero hacia un modelo Scrum-Ban (la diferencia es que no evolucionamos a partir de Scrum sino todo lo contrario) pero siempre manteniendo la disciplina de Kanban de limitar el WIP o trabajo en progreso explícitamente a nivel de las historias (más no a nivel de tareas ya que nunca lo consideramos práctico). La figura 3 muestra este tablero.

Figura 3. Tablero avanzado.

Conclusiones
Kanban se implementó sin entrenamiento y sin disrupción en el trabajo desde el primer día, tampoco se cambiaron los roles. Luego de 8 meses, como resultado de un cambio cultural profundo el CEO de la compañía finalmente había logrado el nivel de agilidad de negocio que jamás pensó en tener desde que se inició el desarrollo de la primera versión del proyecto (un CRM).
Hoy en día el equipo es auto-organizado y autónomo. El método Kanban ha generado una evolución hasta el punto de parecernos a un equipo Scrum, digamos que evolutivamente hemos ido orientándonos hacia un Scrum sin sprints pero de manera muy sutil, en pasos muy pequeños, logrando con cada paso el consenso colectivo y la comprensión del equipo de los principios detrás de las prácticas, la medición continua de datos cuantitivos pero sin descuidar el aspecto cualitativo y humano en el trayecto.
El viaje ha sido una experiencia de aprendizaje para el equipo y el coach, sin estresar al equipo al pretender que trabajen por encima de su capacidad. Hemos construido un equipo efectivo que hoy trabaja con un proceso también efectivo y que sigue evolucionando en un entorno donde el cambio ya no asusta ni al cliente ni al equipo de trabajo.

Referencias:
[1] L. Adkins. Coaching Agile Teams. Addison-Wesley Professional, 2010.