Scrum en su propuesta esencial no plantea ningún mecanismo para visualización del estado de los ítems de trabajo, ni tampoco entra en aspectos del flujo de trabajo (workflow) que cada ítem sigue desde que se crea hasta que se termina.
Los tableros kanban han demostrado su efectividad en diferentes ámbitos de trabajo. La idea de utilizar un tablero kanban en el contexto de Scrum es bastante natural, pues ofrece dicha visualización y workflows para poder hacer un seguimiento visual de los ítems, estén en el Backlog o en un sprint, es decir, las actividades de interés se verán reflejadas como columnas del tablero kanban y de izquierda a derecha reflejarán el flujo de trabajo.
Algunas actividades normalmente se realizarán en el Backlog y otras durante el sprint. Sin entrar en debates respecto de las diferencias entre Scrum y Kanban (diferencias que efectivamente existen), o los inconvenientes de mezclarlos, me quedo con la idea de sacar lo mejor de ambos.
Así pues, la idea tras Scrumban es utilizar, en el contexto de Scrum, una variante de tablero kanban, específicamente para la visualización del trabajo, sin necesariamente seguir todas las reglas del método Kanban.
Cada actividad realizada para un ítem se pondrá como una columna, cuyas sub-columnas corresponden a To Do, Doing y Done. Como en todo tablero kanban de pared, los post-it que representan a los ítems de trabajo fluyen de izquierda a derecha hasta alcanzar el estado Done de la última actividad. Las actividades incluidas en el tablero dependen del interés del equipo por tener un seguimiento y visualización de mayor o menor detalle respecto de cada ítem. Así, las columnas del tablero expresan un workflow secuencial por el cual fluirán los ítems.
Un tablero de pared para apoyar Scrumban y usando post-it es un excelente medio para ilustrar y aprender la mecánica de trabajo de Scrum. Además, para un equipo que se inicia en agilismo es un mecanismo muy socializador e incluso entretenido.
Las dos alternativas básicas en cuanto a cómo se pasan los ítems desde el Backlog al trabajo diario del equipo son:
a) Los ítems se atienden según se reciben. El equipo, cuando puede abordar nuevo trabajo, simplemente lo coge del Backlog siguiendo el orden establecido.
b) Los ítem se atienden en grupos para los cuales se hace una previsión o compromiso de entrega, acorde con la capacidad del equipo (Sprint). El equipo prepara los ítems antes de implementarlos, pues requiere definirlos y estimarlos para contrastar el esfuerzo requerido respecto de su capacidad.
A primera vista, la lectura de (a) versus (b) podría parecer Kanban versus Scrum :-). Pero ¿por qué NO hay que tomarlo como la selección de uno de esos métodos?. Si se plantea en esos términos cerraríamos la posibilidad de mezclar prácticas (si nos pusiésemos "puristas" en la aplicación del correspondiente método), o por el contrario asumiríamos otras prácticas del método seleccionado que podrían no interesarnos. Más aún, puede que el método en su propuesta nos obligue a un nivel de aplicación de una práctica el cual no nos resulte factible o conveniente de implantar considerando el contexto actual del equipo.
Lo que es evidente es que en (a) basta con priorizar los ítems antes de abordarlos, y en (b) además de priorizar, se planifica acorde a la capacidad. En (b) se requiere algún mecanismo de estimación de los ítems y correspondientemente algún nivel de definición del ítem (al menos para poder establecer su estimación). PERO, lo anterior no descarta que en (a) pueda existir la conveniencia de definir y estimar (en alguna medida) los ítems antes de abordarlos, tampoco descarta en (b) la conveniencia de NO definir (ni estimar) en detalle los ítems antes de abordarlos. Es decir, el nivel de detalle en el cual se lleva a cabo la definición y estimación puede dar cabida a dichas actividades, independientemente de si la estrategia es concentrarse en generar flujo de entrega de trabajo terminado (enfoque Kanban) o si es realizar entregas frecuentes de trabajo agrupado en sprints (enfoque Scrum).
En (a) podríamos NO tener todos los ítems necesariamente definidos y estimados antes de abordarlos. Así, en el caso (a) un ítem podría incluso alcanzar su prioridad y comenzar a ser abordado, y ya en ese momento definirlo y acordar con el cliente el detalle necesario. Sin embargo, en (b) lo ideal sería tenerlos todos definidos y estimados antes de abordarlos en un sprint. Así, en el caso (b) cuando un ítem esté próximo a ser incluido en un sprint sería conveniente definirlo en mayor detalle y estimarlo (por ejemplo, en Puntos u Horas Ideales) para poder hacer una previsión de si se conseguirá o no entregarlo en un sprint (considerando el resto de ítems que se incluirían en dicho sprint).
En cualquiera de los casos (a) o (b) es importante tener presente el riesgo que supone definir y estimar de forma anticipada ítems que no están comprometidos y/o que no formarán parte de una próxima entrega. Dicha definición y estimación puede quedar obsoleta, el ítem podría perder prioridad o incluso ser desestimado. En ambos casos también es importante que la posible descomposición o estructuración del trabajo asociado a un ítem de gran tamaño (Épica) también se postergue hasta que el ítem esté próximo a ser abordado por el equipo y ser entregado al cliente. Así pues, no nos debería incomodar tener ítems en el Backlog que no tengan una definición o estimación detallada (o que incluso no la tengan), ni que tengan un tamaño relativamente grande, mientras NO estén próximos a ser cogidos para ser implementados. Por ejemplo, se podría tener un ítem por un tiempo en el Backlog sólo con una breve definición y opcionalmente una estimación a priori (en Puntos, Tallas o algo similar) para advertirnos si se trata de una Épica.
Por otra parte, para abordar una Épica existen varias alternativas, por ejemplo, mantenerla como tal en el Backlog y de ella ir paso a paso derivando ítems más pequeños que se van abordando hasta finalizar la Épica, o reemplazarla por un conjunto de ítems relacionados (que pueden corresponder a incrementos sucesivos y/o partes).
Insistiendo en las mezclas de prácticas y su adaptación al contexto, a continuación comento escenarios que ilustran que aún en el caso (a) o (b) hay más variedad posible :
Podría darse un caso (a) en el cual interese poder consultar el histórico del trabajo asociado a un producto o servicio, y para esto sea conveniente definir sprints a posteriori, es decir, una vez ya entregados los ítems, éstos queden agrupados bajo el nombre de un sprint (por tener asociado un período de tiempo y/o la versión del producto en la cual se entregaron ciertos ítems).
Podríamos estar en el caso (b), y además, disponiendo de flexibilidad (y complicidad con el cliente) respecto del alcance del sprint (ítems incluidos en el sprint), los ítem podrían ser definidos y estimados de forma muy preliminar antes de comenzar el sprint, y luego durante el sprint asumir que podrían algunos de ellos no alcanzarse a implementar y tener que ser devueltos al Backlog o considerados para el siguiente sprint.
Quizás la mezcla más evidente (y comúnmente aplicada) es la de utilizar un Scrumboard cuando se trabaja con sprints. Scrum en su propuesta original no ofrece ningún mecanismo para la visualización del trabajo dentro del sprint, debido a esto es muy recomendable siempre usar un tablero kanban (que es el mecanismo básico del método Kanban). Esta mezcla tiene la denominación (más o menos aceptada) de Scrumban, finalmente se mejora la gestión de la información, se mezclan métodos, obteniendo lo mejor de cada uno y se mantiene un rumbo claro y visible para la evolución del proyecto, independiente de ser realizado con herramientas online o con tableros en papel.
En internet abundan ejemplos de tableros kanban manuales, así como heramientas online de tableros kanban. Sería entrar en la guerra entre un tablero en pared ó un soporte online de tablero, pero ese es otro tema muy interesante a tratar en otro artículo.
