Una Solución pre-Scrumban / A pre-Scrumban Solution

Hace unos meses, leyendo las aportaciones de la comunidad española que trabaja con prácticas ágiles, me topé por primera vez con el término “Scrumban”. A partir de allí me leí el estupendo paper de Kanban vs SCRUM, y me alegré al saber que compartía problemas con ellos y podía leer sobre sus soluciones.

En este post, voy a centrarme en un problema que me he encontrado en el pasado y en una solución que adopté, y en siguientes posts voy a estudiar cómo se relacionan con las tendencias Scrumban que mis compañeros de agilismo están explorando.

En proyectos en los que he implantado SCRUM, había una serie de problemas recurrentes. Uno de estos problemas era qué hacer cuando el equipo de desarrollo también realiza tareas de soporte. Muchas veces, el equipo de desarrollo no sólo tiene que desarrollar nuevas funcionalidades, sino también arreglar bugs y realizar soporte puro y duro. En compañías grandes, los equipos suelen estar diferenciados, pero cuando se trata de empresas pequeñas, los desarrolladores tienen que contestar el teléfono y “apagar fuegos”.

El problema con SCRUM es que no permite incluir tareas nuevas cuando un Sprint ha empezado. Esto no es una restricción caprichosa, pues tiene un buen fundamento: hay que acotar el nivel de cambio dentro de un equipo para poder entregar el paquete de software prometido a final del Sprint. Si estamos cambiando continuamente el alcance de un Sprint, los conceptos de velocidad y compromiso por parte del equipo a entregar lo acordado para ese Sprint, se pierden. ¡No vamos a comprometernos a entregar algo que no sabemos qué es!

Pero si el equipo de software también tiene que ofrecer soporte... ¿cómo podemos decirle a un cliente (usuario, manager…) que tiene que esperar a que el Sprint se acabe para solucionar el problema? Aunque el problema sea urgente, tendrá que esperar a que el Sprint acabe, se priorice la solución en la pila de producto (por el Product Owner) y finalmente, se entregue al final del Sprint siguiente (supongo que, como el problema era urgente, el Product Owner lo prioriza). En el mejor caso, si el problema sucede el último día de un Sprint, el tiempo de respuesta seria la duración del siguiente. Y en el peor, si sucede el primer día del Sprint, dos veces esta duración. E incluso podríamos calcular un tiempo medio de respuesta, haciendo estadísticas de cuando suceden los problemas durante un Sprint en nuestra compañía, calculando su distribución temporal y obtener un tiempo medio de finalización del Sprint en curso (al que sumaríamos después la duración del siguiente). Sea como sea, esto no funciona si el problema es realmente urgente y se debe solucionar.

En un pasado, yo utilicé un método “híbrido”: bajábamos la velocidad de equipo de forma artificial para dejar un buffer para “soporte”. Hay que recordar que en SCRUM, los equipos son multifuncionales y por lo tanto todos los miembros del equipo podían realizar soporte. Definíamos una serie de tareas del Product Backlog como “opcionales”, utilizando una versión reducida del Moscow Method:

- Tareas M “Must”: conformaban el Sprint, el compromiso del equipo.
- Tareas S “Should”: estas tareas se realizarían si no había tareas de soporte. En caso de que surgieran dichas tareas, las tareas “Should” podrían descartarse. No formaban, a priori, parte del compromiso del equipo con el cliente.

Este método no es perfecto, pues también limita la capacidad de soporte del equipo, pero dicha capacidad máxima de soporte era algo que se acordaba con los clientes/usuarios. Por ejemplo, “el equipo dedicará un máximo de 20% a soporte”. Entonces “Tareas Must” = Compromiso = Velocidad - 20%. Si no se realizaban tareas de soporte, el equipo debía realizar las tareas “Must” y “Should”. Las soluciones de bugs se ponían en producción cuando el Sprint finalizaba, con lo que el tiempo de respuesta se reducía.

A few months ago, reading the contributions of the Spanish community working with agile practices, I first encountered the term "Scrumban". Afterwards I read the great paper of Kanban vs. Scrum, and I was glad to realise that I had similar problems than those they had, and I could read the solutions they propose.

In this post, I will focus on a problem I've encountered in the past and I a solution I once adopted, and in following posts I will explore how this relates to the trends my fellow agile buddies are exploring

In projects where I have implemented SCRUM, there were a number of recurring problems. One of them was what to do when the development team also performs support tasks. Often, the development team must not only develop new functionality, but also fix bugs and offer support. In large companies, teams are normally different, but when it comes to small businesses, developers have to answer the phone and "put out fires".

The problem with SCRUM is its inability to include new tasks when a Sprint has started. This is not a capricious restriction, as it has a good reason: we must limit the level of change within a team, so it can deliver the promised software package at the end of the Sprint. If we are constantly changing the scope of a Sprint, the concepts of speed and commitment to deliver are lost. We cannot commit to deliver something if we do not know what is!

But if the software team must also offer support... how can we tell a client (user /manager...) that has to wait until the Sprint is finished to get the problem fixed? Although the problem is urgent, the user has to wait for the Sprint to finish, for the Product Owner to prioritize the solution in the Product Backlog and finally, for the next Sprint to finish (I am assuming that, since the problem was urgent, the Product Owner will prioritise it). Best case scenario, if the problem happens on the last day of a Sprint, the response time would be the duration of the next Sprint. Worst case, if it happens the first day of Sprint, twice this duration. We could even calculate an average response time, by collecting statistics of when problems occur during a Sprint in our company and get an average time for the current Sprint (which would add after the duration of the next). Anyway, this does not work if the problem is really urgent and must be fixed.

In the past, I used a “hybrid” method: we artificially lowered the velocity of the team, to have a buffer for "support”. We have to keep in mind that in SCRUM, teams are multifunctional and therefore all team members could perform support. tasks. We then identified a number of tasks of the Product Backlog as "optional", using a reduced version of the Moscow Method:

- Tasks M "Must": as the Sprint, the team's commitment.
- Tasks S "Should": these tasks would be made if there was no support tasks. In the event of any such tasks, the tasks "Should" could be dismissed. They were not, a priori, part of the team's commitment to the customer.

This method is not perfect; it also limits the ability to support the team, but the capacity of the team for support was something that was agreed with customers/users. For example, “the team will spend up to 20% for support”. Then “Must tasks” = Commitment = Velocity - 20%. Although, if no support tasks were performed, the team was expected to fulfil “must” and “should” tasks. This way, the support fixes were put into production when the Sprint ended, and the response time was reduced.