¿Alguna vez has sentido que tal vez una estrategia diferente podría ayudarte a ser más flexible ante los cambios comerciales continuos mientras trabajabas en un proyecto? Los equipos se suelen enfrentar a la decisión de implementar un marco ágil, y el más usual es Scrum. Pero esta no es siempre la opción más adecuada para alcanzar nuestros objetivos. Les voy a explicar de qué manera Kanban ayudó a mi equipo a aumentar la satisfacción de las partes interesadas y a organizarnos mejor como grupo.
¿Scrum es adecuado para este proyecto?
Hace un año, nuestro equipo tenía como objetivo implementar cambios de software en diferentes áreas comerciales de una empresa minorista. En un principio, decidimos implementar el marco Scrum. Una frecuencia de sprints de dos semanas nos permitiría concentrarnos en el objetivo del sprint y recibir comentarios comerciales en la revisión.
Nuestra idea era ubicar a las historias de usuario más importantes para el negocio en la cima del backlog. A veces, debíamos tomar la decisión de reemplazar una historia de usuario que ya estaba en progreso en el sprint por otra que había aparecido de repente en el radar comercial. El problema es que esta situación se volvió muy frecuente y los requisitos que iban surgiendo eran difíciles de añadir durante el sprint.
Los equipos que han implementado Scrum saben que el marco tiene algo de flexibilidad. Es posible reemplazar elementos en el backlog si las prioridades para el producto cambian de manera repentina durante la ejecución del sprint. Pero, en este caso, esa situación no era excepcional sino constante. Entonces, ¿cómo podíamos gestionar nuestro flujo de trabajo para poder reaccionar mejor ante estos cambios impredecibles? Y, por otra parte, ¿eran en verdad cambios en las prioridades comerciales? ¿O estábamos dejando de lado el aporte de alguna parte interesada a la hora de definir los objetivos del sprint?
Analizar y adaptar el proceso
En primer lugar, el propietario del producto confirmó que esos cambios repentinos eran en verdad parte del contexto comercial. Las diferentes partes interesadas que solicitaron nuestros servicios representaban a varias áreas comerciales. La tarea de fijar prioridades en base a la urgencia e importancia de sus requerimientos era volátil y difícil de predecir.
Por lo tanto, decidimos adaptar nuestro proceso con el objetivo de hacer planes a corto plazo y ser capaces de reaccionar con más velocidad a los posibles cambios. El método Kanban resultó ser el más adecuado para llevar adelante nuestro flujo de trabajo, y el propietario del producto apoyó esta decisión. Pero aún se nos presentaban interrogantes, algunas relacionadas a nuestro equipo y otras vinculadas a las partes interesadas.
- Internalización de Kanban por parte del equipo
En las reuniones retrospectivas anteriores, el equipo había notado que una estrategia diferente nos podría ayudar, por lo que estábamos abiertos a cualquier cambio. Sin embargo, no todos tenían experiencia previa con Kanban por lo que el paso de un proceso a otro podía ser confuso. Si bien la forma más común de adoptar Kanban en el equipo consiste en que los líderes expliquen los conceptos y definan las reglas iniciales, nosotros intentamos algo diferente. Jugamos a un juego llamado «Pizza Kanban», una adaptación de esta dinámica para enseñar conceptos básicos. La idea es descubrir como equipo y de manera iterativa cuál sería la mejor distribución para generar un flujo constante para cocinar la mayor cantidad de pizzas posible. Atravesamos varias de las situaciones que se presentan cuando un equipo implementa un sistema «pull», y este juego nos ayudó a comprender los valores, principios y prácticas de Kanban. La lección más importante que aprendimos del juego es «dejar de iniciar y empezar a terminar».
Como resultado, definimos los límites del trabajo en proceso y desarrollamos una idea inicial de cuándo consideramos que un elemento está listo. Claro, fue más sencillo para nosotros porque ya habíamos trabajado con Scrum antes y mantuvimos los roles y las responsabilidades. Además, continuamos celebrando nuestras reuniones diarias, así como las reuniones retrospectivas cada dos semanas.
2. Involucra a las partes interesadas con Kanban
El proyecto estaba en marcha, así que corríamos el riesgo de no alcanzar la fecha de entrega de las historias de usuario que estaban en progreso. Usamos el proceso STATIK (del inglés «Systems Thinking Approach to Implementing Kanban») para determinar con certeza la demanda, la capacidad y los puntos débiles. Identificamos prioridades que no habían sido definidas de forma correcta debido a fallas en la comunicación con algunas de las partes interesadas. También notamos que si reorganizábamos la forma en que fijábamos prioridades, podíamos establecer expectativas más adecuadas con dichas partes interesadas sobre cuándo un elemento de trabajo estaba terminado.
Decidimos celebrar una reunión de restablecimiento cada dos semanas con todas las partes interesadas y animarlas a que participen. Este evento les permitió comunicar sus necesidades y las razones detrás de cada nuevo requerimiento en frente de sus pares. La idea era que el propietario del producto promoviera la comunicación y escuchara lo que cada uno tenía para decir. Luego de un saludable debate, podíamos decidir cuáles de estos requerimientos podrían abordarse primero.
3. Las clases de servicio como prioridad
La participación de las partes interesadas era importante, pero el método para darle prioridad a sus requerimientos era aún más importante si queríamos ser transparentes a la hora de decidir qué historia de usuario abordaríamos primero. Queríamos ser justos y emplear criterios inteligentes para ajustar nuestro backlog sin hacer sentir incómodos a los usuarios. Decidimos experimentar con el uso de Clases de Servicio (CoS), una herramienta versátil para afrontar las situaciones inciertas e impredecibles. Nos permitiría gestionar las dependencias para los elementos de trabajo de acuerdo al coste del retraso (CoD), es decir, el impacto económico que resulta de no lograr entregar el servicio a tiempo.
Analizamos qué tipos de requerimientos habíamos recibido en el pasado. Eran diferentes porque, en ocasiones, un área empresarial solo quería una funcionalidad de mera conveniencia en un proceso. En otros casos, las áreas necesitaban una funcionalidad esencial que podría generar pérdidas significativas si la implementación se retrasaba. Así fue como decidimos qué criterios usaríamos para definir a un elemento como Expedito, de Fecha Fija, Estándar o Intangible.
Nuevo análisis: ¡estamos mejorando!
Luego de varios meses aplicando estos cambios, recibimos buenos comentarios de las diferentes áreas comerciales y aprendimos varias cosas diferentes:
- Limitar el trabajo en progreso (o WIP): esto nos ayudó a mejorar la colaboración e implementar el sistema «pull». Cada vez que una de las historias se complica, celebramos una reunión en equipo para buscar formas de terminar la historia en lugar de comenzar una nueva. Nos sorprendió ver que un desarrollador con gran conocimiento empresarial pasó una semana completa ayudando a los testers a alcanzar la definición de «hecho» en algunas historias de usuario antes de comenzar a desarrollar una nueva. Utilizamos un Diagrama de Flujo Acumulado para determinar de manera periódica si los límites ayudaban a mejorar el flujo de trabajo.
- Visualizar el flujo de trabajo: fuimos muy transparentes en el tablero Kanban. Cuando una historia de usuario se bloqueaba, la dejábamos en el tablero ocupando un espacio disponible. Eso nos obligaba a conversar con otras áreas de IT para obtener ayuda y desbloquear el elemento. Además, nos permitía brindarles visibilidad a las partes interesadas sobre el progreso del proyecto y hacerles saber si necesitábamos una respuesta comercial para desbloquear algún elemento, siempre teniendo en cuenta que ese tiempo de espera impediría que otras áreas recibieran nuestra atención.
- Acordar la definición de urgente: las reuniones de restablecimiento con todas las partes interesadas cada dos semanas fueron la oportunidad ideal para compartir con ellos qué elementos se habían completado y entregado, y para entender sus necesidades y expectativas. Nos resultó sorprendente el hecho de que, en el pasado, algunas partes interesadas habían intentado darles prioridad a sus requerimientos catalogándolos de «urgente» porque querían asegurarse de que estuviesen listos para una fecha específica. De a poco, el equipo fue ganando la confianza de las partes interesadas gracias a nuestra implementación continua de funcionalidades. Además, gestionamos las métricas para detectar si había áreas que estaban siendo relegadas por mucho tiempo para ayudarlas a justificar sus requerimientos utilizando la herramienta de clases de servicio.
Conclusión
Con este artículo no pretendemos afirmar que Kanban es mejor que Scrum, o viceversa. No existe una receta estática para determinar cuál de los dos funcionará mejor en determinada circunstancia. La idea es que siempre tengas en mente que elegir un marco o método para un proyecto es solo el primer paso. El siguiente paso es cuestionarse como equipo y de forma periódica qué cosas están funcionando bien y qué cosas no. Debemos estar abiertos a adaptar nuestros procesos de acuerdo con los cambios del entorno y el contexto de la situación.
