archivo

Archivo de la etiqueta: scrumban

Veamos una posible implementación Scrum-dominante. Dentro del flujo de trabajo que se defina en un tablero Scrum, supongamos que se definen un conjunto de fases tan simple como: Sin iniciar, en construcción, testing y finalizada, y para una o más de ellas se establece un límite de tareas abiertas de manera que si se alcanza el límite ninguna tarea más puede entrar en esa fase, lo que hace que los esfuerzos se deban enfocar en eliminar ese cuello de botella: deben salir tareas para que puedan entrar otras. De esa manera se pretende detectar problemas lo más próximo posible a su origen para tratar de resolverlos lo antes posible (filosofía lean).

Veamos ahora una posible implementación Kanban-dominante. En este caso, el sprint está abierto, pueden ir entrando nuevas tareas siempre y cuando no se sobrepase el WIP definido.

Llegado un punto (se puede denominar punto de ajuste) tendremos que ir cerrando la iteración, lo que obligará a centrarnos en aquellas tareas en ejecución que se consideren más prioritarias, lo que implicará que determinadas tareas ya iniciadas pasen a ser trabajadas en futuros sprints. Ese punto de ajuste deberá realizarse con suficiente antelación porque de lo contrario puede haber un mayor número de tareas que queden abiertas y/o que dentro de las que ya se ha comenzado a trabajar haya algunas prioritarias que queden sin ser atendidas.

Hemos visto dos posibles implementaciones, en función de que se pretenda que predomine Scrum o Kanban. También existen otras en las que pueden convivir ambas estrategias, una de ellas puede consistir en que el sprint se realice según las prácticas de Scrum y por otro lado, tener reservada cierta capacidad del equipo de trabajo para resolver incidencias u otro tipo de peticiones que tengan que ser atendidas con urgencia sin alterar los compromisos adquiridos en la iteración (pila de sprint).

Esta capacidad se regiría por prioridades y limitando el WIP.

Esta última implementación me parece muy interesante y es bastante efectiva. Puedes empezar a practicarla sin definir WIP (aunque ya no estaríamos aplicando Kanban) y más adelante empezar a ajustar límites en determinadas tareas del flujo.

Scrumban es el resultado de combinar prácticas de Scrum con Kanban. Sería más ortodoxo decir que es la combinación de Scrum (puro) con Kanban pero la realidad es que no son muchos casos en los que organizaciones o equipos aplican Scrum al pie de la letra y no es porque no exista voluntad de hacerlo, sino porque la realidad de muchos proyectos lo impide.

Es cierto que la Scrum Guide dice que si solo se implementan partes concretas de Scrum no se puede considerar Scrum, y lo respeto, por ese motivo prefiero hablar generalmente de prácticas de Scrum en lugar de utilizar de manera rotunda la palabra Scrum.

No obstante, en este artículo cuando la utilice, me gustaría que lo entendieráis como su conjunto de prácticas (roles, eventos, etc…), independientemente de que las utilice todas o no o haya alguna sobre la cual se aplique un enfoque diferente, ya que resulta más interesante entrar a analizar cómo se puede combinar con Kanban.

Realmente y como os he insistido en muchas ocasiones, no podemos considerar una herramienta, una metodología o una estrategia por muy interesante y práctica que ésta sea como para que todo nuestro trabajo gire alrededor de ella. Le damos el valor que se merece pero nunca por encima de las necesidades de un proyecto, sin hiciéramos lo contrario no estaríamos siendo ágiles.

Hay muchas implementaciones posibles de Scrumban porque se trata, como dice, Henrik Kniberg de obtener lo mejor de ambas. Os recomiendo la lectura de su libro: “Kanban y Scrum, obteniendo lo mejor de ambos”.

Simplificando, podríamos decir que se trataría de añadir el concepto de gestión visual del flujo de trabajo (si bien esta práctica se aplica prácticamente de serie en muchos equipos que utilizan Scrum) y el WIP (Work in Progress) a Scrum, con el objeto de detectar cuellos de botella dentro de cada sprint. Sin embargo, depende mucho de la implementación que se vaya a realizar, ya que si un equipo está habituado a trabajar con Kanban, podría decirse que Scrumban se trataría de añadir el concepto de sprint a Kanban.

También existen estrategias que combinan en flujos de trabajo diferentes ambos enfoques.

En el siguiente artículo veremos algunos ejemplos de implementaciones de Scrumban.

Mientras el producto no esté en producción y, por tanto, no empiecen a llegar incidencias con diferente grado de prioridad y en cualquier momento, puede resultar relativamente sencillo mantener un determinado nivel de predecibilidad en los sprints, de manera que salvo errores importantes en las estimaciones se ejecutarán la mayor parte de las historias de usuario o incluso todas ellas.

Sin embargo, en el momento en que empiezan a llegar incidencias, la cosa cambia. Si no tienes capacidad de “reserva” para afrontarlas tocará tomar determinadas decisiones y para ello nos podemos hacer una serie de preguntas:

– ¿Dejo las incidencias para el siguiente sprint?.

Dependerá de la urgencia de las mismas y de lo que queda para que finalice el sprint, habrá veces en que se pueda aplazar al siguiente sprint, otras en las que incluso se dejará para más adelante y otras donde la criticidad haga que tengas que ponerte con ellas nada más conocer de su existencia.

– ¿Anulo el sprint e inicio uno nuevo en el que ya tenga en cuenta estas incidencias que han llegado?.

En este caso dependerá del número de incidencias y de su complejidad (además, como es lógico de su criticidad). Si vamos a tener que dedicar gran parte de la capacidad a trabajar en ellas, mantener el sprint definido deja de tener sentido. ¿Es la solución definir un nuevo sprint? Sí, pero en situaciones de inestabilidad, tal vez lo mejor sea que tengamos más peso de Kanban que de Scrum.

– ¿Cambio alcance del sprint de manera que sustituyo la realización de determinadas historias de usuario a cambio de las incidencias?.

Puede ser bastante práctico pero dependerá de las incidencias que lleguen porque si terminan desvirtuando el sprint, tal vez lo mejor sea cambiar de enfoque.

– ¿Introduzco las incidencias como parte del alcance del sprint, retrasando la finalización del mismo?.

La respuesta es similar a la anterior y dependerá también del contexto y situación del proyecto, de las incidencias y de lo que pueda aportar a la productividad de los equipos y a la efectividad de los trabajos mantener inamovibles la fecha de finalización de lo sprints.

Lo que quiero que saquéis como conclusión es que no es posible formular una solución que valga para todo. Tenéis que analizar qué os conviene más y siempre con una mentalidad abierta, más allá de la ortodoxia de la aplicación de una determinada estrategia o metodología.

No obstante, puede ser interesante, aún no siendo tampoco una solución universal, dejar siempre capacidad libre del equipo para atender a estas incidencias, de manera que no sea necesario mover el alcance del sprint salvo situaciones de saturación. Esa capacidad variaría en función de la estabilidad del producto y de las implantaciones (y de su importancia) que se estén realizando en ese momento.

¿Y si no se usa esa capacidad? Esa capacidad sobrante se puede utilizar para muchas cosas, desde tareas propias de infraestructura, programación por pares, realizar actividades opcionales sobre determinadas historias de usuario, etc…