Una de las cuestiones que se plantean habitualmente en organizaciones, equipos y Agile Coaches, es el uso de un método que permita organizar el trabajo de forma ágil. El uso de un método como Scrum o Kanban va mucho más allá del proceso en sí, sino que suponen una herramienta para mejorar la capacidad de adaptación, gestión de riesgo e innovación.
El método más usado del mundo es Scrum. Según el informe CHAOS de Standish, Agile tiene cuatro veces más probabilidad de éxito que los métodos tradicionales en proyectos de IT. Kanban le ha ido comiendo terreno, especialmente debido a su baja disrupción de los procesos existentes en la organización.
A primera vista, puede parecer que Kanban es una alternativa a Scrum y viceversa, sin embargo no es así. Son dos maneras distintas de llegar al mismo sitio: la agilidad organizacional. Veamos las diferencias entre Scrum y Kanban.
Primer round: Scrum no funciona porque no podemos planificar. Utilicemos Kanban.
Algunos equipos se encuentran que en su camino hacia la agilidad, usando Scrum se encuentran con muchas interrupciones durante su trabajo diario.
Los miembros de los equipos de desarrollo o el Product Owner, avisan de que dada la naturaleza de su trabajo (gestionar incidencias, por ejemplo) no son capaces de hacer reuniones de planificación cada dos semanas, necesarias para que Scrum funcione.
También se quejan de la imposibilidad de cambiar el commitment para acomodar el trabajo no planificado y que al final no son capaces de entregar todo lo que se habían propuesto. La gestión de la demanda no es adecuada y buscan una alternativa en el método de trabajo, en lugar de en resolver esos problemas de gestión de la demanda.
Por tanto se pasan a Kanban.
Cuando empiezan a hacer Kanban, lo tienen todo en un tablero con Post-its®. Como tienen tanto trabajo, no pueden limitar el WIP (Trabajo en curso).
Tampoco realizan reuniones de Replenishment, y los daily meetings no sirven para gestionar el flujo de trabajo. Solamente se distribuyen tareas. A veces ni eso. Las clases de servicio no están claras y todo es trabajo urgente que hay que hacer "para ayer".
Finalmente, deciden quedarse con el tablero para visualizar notas que viajan de un sitio a otro y descartar los demás elementos necesarios en un sistema Kanban. Un momento: ¿No es esto lo que estaban haciendo con Scrum?
Algunas conclusiones:
- La duración de los Sprints en Scrum se deciden en función del tiempo que necesita el equipo para entregar un incremento y de un horizonte de planning aceptable para el Product Owner.
- Si no podemos planificar a dos semanas, igual tenemos que planificar a una, o a dos días.
- Los Daily Scrums sirven para hacer gestión de riesgos y ver el trabajo urgente, que se incorporará al Sprint Backlog en función de las prioridades del negocio.
- Kanban necesita de WIP, visualización, clases de servicio y feedback loops. Más en el siguiente round.
Segundo Round: Utilizamos un tablero con Post-its® dentro de Scrum para distribuirnos el trabajo, ¿Hacemos Scrum o Kanban?
No. El simple hecho de poner post-its® en un tablero o en una pared no convierte a tu equipo en un equipo Kanban. El método Kanban tiene seis prácticas generales que se usan para gestionar el flujo de trabajo.
Puede ser que utilices un tablero para gestionar el flujo de trabajo dentro de Scrum. Puede o no ser un tablero Kanban. Incluso si usas un sistema Kanban completo dentro de Scrum, puedes seguir llamándolo Scrum. O Scrumban.
Ambos se complementan, no son una alternativa el uno al otro.
Kanban, al igual que Scrum, se basa en la autoorganización de la gente alrededor del trabajo, no en la asignación de tareas.
Un sistema Kanban tiene políticas explícitas que se exponen en el tablero. ¿Las tiene tu tablero Scrum? Si no las tiene, quizás existan pero no sean explícitas. En ocasiones los miembros de los equipo desconocen dichas políticas: ¿Cómo se determina la urgencia de algo? ¿Quien decide que se hace? ¿Cómo sabemos que algo está terminado?
Algunas conclusiones:
- Scrum y Kanban se basan en la autoorganización y la optimización del sistema, no de las personas.
- En un entorno donde se prioríza la "gente ocupada" sobre la "gestión del flujo de valor" ni Scrum ni Kanban aportarán nada a la organización.
- Algunas organizaciones simplemente cambian de Scrum a Kanban y viceversa porque no son capaces de resolver problemas internos.
- Adaptar Scrum o Kanban no resuelve tus impedimentos organizacionales. Sólo los hace más visibles.
Último round: En un equipo maduro, ¿Utilizamos Scrum o Kanban? ¿O lo mejor de dos mundos?
Tu equipo es muy maduro. Tenéis que decidir si usar Scrum o Kanban. ¿Lo mejor de dos mundos?
Cuando un cliente me dice que usa lo mejor de "Scrum y Kanban" automáticamente se que tiene un problema. Hablan sobre métodos para no hablar de sus impedimentos. Los equipos y organizaciones maduras no tienen este problema.
Las organizaciones maduras entienden que al final todo lo que pueden hacer está gobernado por la Ley de Little, que es una demostración de la relación directa de la capacidad de un sistema, la velocidad a la que llegan las cosas y el ratio de entrega de cosas finalizadas.
Este video sobre el WIP lo explica mucho mejor.
Como ves, no hay tantas diferencias entre Scrum y Kanban. Son maneras distintas de llegar al mismo resultado y ambas requerirán que tu organización cambie para adaptarse a ellas y no al revés.
Sí que hay una gran diferencia entre ambas: Implementar Scrum supone un impacto grande en la forma de trabajar en la organización, mientras que la implementación de Kanban usando STATIK sigue el camino de menos resistencia.
Tarde o temprano, tendremos que implantar una cultura de transparencia, inspección y adaptación, lo que requerirá cambiar nuestra organización. No importa el camino que elegimos. Importa lo que hagamos en el mismo.
En realidad, cuando las organizaciones y los equipos discuten si usar Scrum o Kanban, están discutiendo otro asunto: ¿Qué es lo que nos implica tocar menos el statu quo? Ni Scrum ni Kanban te ayudaran a mantener el status quo de tu organización. Precisamente todo lo contrario.