En un post reciente en un foro técnico, un gerente de desarrollo tenía la pregunta (parafraseada aquí) – Mi organización quiere operar de una manera Kanban, pero mantener la estructura de los sprints y los gráficos de quema para realizar un seguimiento del progreso. ¿Está bien hacerlo? ¿Es Scrumban la metodología correcta? Si es así, ¿cuál es la mejor manera de implementarla?
Esta es una pregunta bastante común que tienen muchos equipos ágiles que están empezando a mirar a Kanban. Ustedes son un equipo Scrum con herramientas y prácticas Scrum bien establecidas. ¿Cómo exactamente se empieza con Kanban? ¿Lo que se acaba haciendo se conoce como Scrumban? Implícito en estas preguntas quizás está la preocupación – ¿se diluirán o viciarán de alguna manera mis prácticas y resultados de Scrum?
Me alegré de responder a la pregunta y ¡pareció que les funcionó bien!
¿Qué es Scrumban?
En el nivel más simple, Scrumban es sólo la aplicación de los principios del método Kanban sobre sus procesos de Scrum. Kanban, como aclara David Anderson en su famoso Libro Azul de Kanban, no es una metodología de desarrollo de software o de gestión de proyectos. Es un método para visualizar y mejorar lo que se hace actualmente. Si actualmente usted hace Scrum, todavía puede utilizar Kanban para visualizar su trabajo y mejorar su entrega de productos. A menudo, los equipos que hacen esto llaman al proceso resultante cambiado / mejorado Scrumban.
Los principios fundamentales de Kanban son:
- Visualizar su proceso actual
- Implementar los límites de WIP y el método Pull; y
- Mejorar el Flujo abordando cualquier cuello de botella del proceso y evolucionar gradualmente.
Así que, en palabras de quien pregunta, el hecho de que el equipo quiera mantener los principios de Scrum y «trabajar de forma Kanban» es un punto de partida perfectamente bueno.
Visualice su proceso actual
Comience por definir el tablero Kanban que visualiza el proceso que su equipo Scrum utiliza actualmente para desarrollar, probar y entregar / desplegar las las historias de usuario. En lugar de sólo el tablero Listo-Haciendo-Hecho, amplíe la columna Haciendo en cada paso por el que pasa la historia de usuario.
Aquí, es útil tener en cuenta que muchos equipos sólo visualizan las tareas dentro de cada Historia de Usuario en el Tablero Scrum, no las Historias de Usuario. Con las tareas, es más fácil sólo utilizar la estructura Listo – Haciendo – Hecho para el tablero de tareas. Sin embargo, con Kanban, usted tiene la oportunidad de visualizar las Historias de Usuario en un Scrum Storyboard – que podría ser un Swim Lane de nivel superior en el mismo tablero Kanban, donde se puede definir el proceso de ingeniería detallado por el que pasa una historia de usuario.
Al hacer esto, puede visualizar completamente el viaje de cada historia de usuario a medida que pasa de una etapa a la siguiente, y comenzar a estudiar las anomalías del proceso de manera mucho más eficaz.
Su tablero Kanban podría parecerse al que se muestra a continuación -por supuesto, modelaría su proceso real en el tablero –
El swim lane principal hace un seguimiento de sus historias de usuario. Como se mencionó anteriormente, este carril es el que visualiza el proceso real por el que pasan sus historias de usuario – y le ayudará a identificar los cuellos de botella o las áreas problemáticas en las que sus historias tienden a ralentizarse y a acumularse debido a razones tales como los retrasos en el traspaso, las dependencias externas (a la espera de la confirmación de un cliente, o de que un equipo de infraestructura complete alguna tarea de aprovisionamiento), etc.
Puede tener un carril separado para seguir las tareas asociadas a cada historia de usuario, aunque esto es opcional. Una vez que se acostumbre a la gestión del trabajo a nivel de historia de usuario a medida que la historia pasa por cada etapa del proceso de desarrollo, puede encontrar que las tareas son redundantes.
Definir los límites de WIP
Una vez que se acostumbre a la nueva visualización del tablero Kanban, puede implementar los límites WIP en cada etapa/ paso – para reflejar la cantidad máxima de trabajo que debe haber en cada paso a la vez. Kanban refuerza el principio de reducir la multitarea y terminar lo que ya ha comenzado antes de emprender algo nuevo. (¡Deje de empezar, empiece a terminar!).
¿Cómo se definen los límites del trabajo en curso? Al principio, puede empezar sin límites de trabajo en curso. Una vez que haya observado cuál es el flujo de trabajo típico, podrá decidir la cantidad de Límite WIP que debe especificarse por etapa del flujo de trabajo. Los Límites WIP se muestran como números en cada etapa, como en la imagen siguiente:
Image Courtesy: Pawel Brodzinski
El famoso Don Reinertsen dio la fórmula de definir el Límite WIP como el doble de la media de trabajo en curso que se observa inicialmente. La mayoría de los equipos suelen definir los Límites WIP igual a 1-2 veces el número de personas que trabajan en cada etapa del flujo de trabajo.
Los Límites WIP funcionan como restricciones en un canal por el que fluye el trabajo, de forma similar a las orillas de un canal. Sin las orillas bien definidas (restricciones), el agua tenderá a extenderse y estancarse en lugar de fluir en la dirección deseada. Del mismo modo, los límites del trabajo en curso garantizan que el trabajo ya iniciado fluya hasta el final del flujo de valor antes de que el nuevo trabajo se introduzca en el canal. Una vez que el trabajo se ha introducido, los límites de trabajo en curso ayudan a garantizar que siga avanzando.
La definición de los límites de WIP y la importancia de los límites de WIP has se han tratado también en anteriores entradas del blog.
Solucionar los Cuellos de Botella / Mejorar el Flujo
A medida que su equipo comience a observar el flujo y a evaluar las etapas en las que el trabajo se bloquea, podrá discutirlas automáticamente en sus reuniones de equipo y abordar los problemas a los que se enfrentan. Las soluciones pueden ir desde el ajuste de los límites del WIP en etapas anteriores para regular mejor el flujo, la definición de políticas explícitas (un principio clave de Kanban) para gestionar el trabajo que se está retrasando de forma prioritaria (como las revisiones de documentos y código), el ajuste de la asignación de recursos, etc.
El otro aspecto de hacerlo es fomentar la aplicación de Pull en el sentido real. A la mayoría de los equipos y personas les cuesta decir «no» al trabajo adicional. Definir los límites de WIP les proporciona una herramienta para hacerlo de forma más eficaz, ya que los límites de WIP se definen y determinan conjuntamente por todas las partes interesadas, y proporcionan un contrato explícito a ambas partes de que ninguna etapa del trabajo se sobrecargará. Los equipos pueden decir «no» de forma más eficaz o, al menos, pedir a su cliente que elimine otra cosa si les impone un nuevo trabajo. Esto puede tener un efecto casi mágico en la forma en que el nuevo trabajo «urgente» deja de ser empujado al equipo de entrega!
Pasar de Scrum → Scrumban (→¿Kanban?)
No hay una «mejor manera» prescrita para pasar de Scrum a Scrumban o Kanban, ni es deseable entrar en esa semántica. Usted puede seguir haciendo sólo Scrum, con las características añadidas de Kanban para ayudarle a gestionar mejor el trabajo y mejorar. ¡Usted es libre de llamar al proceso mejorado resultante – que ha sido completamente adaptado a sus necesidades (del equipo) lo que usted quiere!
A medida que comience a introducir Kanban en su equipo, debe seguir utilizando varios aspectos de Scrum como los cubos de tiempo de Sprint de 2 o 3 semanas, las métricas como los gráficos de burndown o de velocidad y otras ceremonias relacionadas con Scrum que están funcionando bien para su equipo especialmente el Standup diario y las Retrospectivas.
Al menos inicialmente, no es necesario cambiar nada en términos de su planificación de lanzamientos y sprints. A medida que se utiliza Kanban de manera efectiva, especialmente los límites de WIP y otros conceptos como la definición de políticas explícitas, el uso de clases de servicio para priorizar el trabajo y el compromiso con los SLAs, es posible que decida hacer cambios en su proceso general que podría incluir el abandono de algunos conceptos relacionados con Scrum como los cubos de tiempo de 2 o 3 semanas, la estimación, etc. ya que Kanban le ayudará a desplegar de manera más continua y le dará la capacidad de hacer previsiones de lo que puede completar en cada cantidad de tiempo.
También puede optar por adoptar métricas adicionales de Kanban, como el Diagrama de Flujo Acumulativo, el Tiempo de Espera y la Eficiencia del Flujo, mientras que deja caer el gráfico Burndown, ya que podría no hacer la estimación o el seguimiento de las horas. De hecho, la propia comunidad de Scrum ya no hace hincapié en la estimación del esfuerzo como algo necesario para Scrum.
Para saber más sobre Scrumban, puede consultar aquí – ¿Qué es Scrumban? – que proporciona algunos detalles más y hace referencia a otros expertos en el tema de Scrumban, como Core Ladas y otros, que podría disfrutar.
Espero que esto ayude. Si necesita más ayuda sobre cómo implementar Scrumban, puede ponerse en contacto con nosotros aquí. Estaremos encantados de ayudarle!
Mahesh Singh
Co-founder, Sr. VP – Marketing, AKT/ KCP
