Scrum y Kanban, lo peor de los dos

No se en cuantas ocasiones es escuchado -y me han preguntado- si la solución a un equipo de soporte es hacer Kanban en lugar de Scrum, o si un equipo que recibe muchas interrupciones debería de pasarse a un sistema Kanban en lugar de Scrum, o hacer Scrumban.

Scrum bien hecho. Scrum mal hecho.

Scrum tiene una serie de premisas:

• Tienes un producto con un Product Owner que se encarga de maximizar su valor.
• Tienes un equipo de desarrollo que trabaja para ese producto.
• Tienes un Scrum Master que gestiona Scrum y sirve al equipo de desarrollo.

Si no tienes un producto, no vas a obtener valor de Scrum. Si no tienes un Product Owner, no vas a obtener valor de Scrum. Si no tienes un equipo de desarrollo, no vas a obtener valor de Scrum. Si no tienes un Scrum Master, no vas a obtener valor de Scrum.

Sí, vale. Puedes hacer Daily Scrums, o Retrospectivas. Pero eso no es Scrum. Simplemente, no lo llames Scrum. Scrum es gratuito y libre para su useo, pero para hacer Scrum necesitas tres roles, tres artefactos y cinco eventos. Puedes hacerlo sin Definition of Done, Sprint Goal o Refinamiento y aún así seguiría siendo Scrum. Pero eso son los básicos.

Kanban bien hecho. Kanban mal hecho.

Kanban necesita una serie de premisas:

• Tienes un flujo de trabajo que puedes visualizar
• Puedes limitar el trabajo en curso (p.e. decir NO cuando algo que alguien considera urgente entra al flujo)
• Tienes control para cambiary gestionar ese flujo de trabajo
• Puedes establecer políticas explícítas (Clases de servicio, Cadencias, etc…)
• El ritmo de llegada de nuevo trabajo es similar al ritmo de salida del trabajo.

Si no tienes un flujo de trabajo, Kanban no te va a aportar valor. Si tienes que decir que SI a todo el trabajo que te entra, Kanban no te va a aportar valor. Si no tienes control sobre tu sistema porque otro decide como funciona, Kanban no te va a aportar valor. Si no puedes decidir sobre las políticas del sistema, bueno… creo que ya está claro.

Si, puedes tener un tablero con Post-its y moverlos de un sitio a otro, asignando avatares y haciendo Daily Stand-ups y simulando que eres ágil. Pero si no cumples esas tres condiciones, a pesar de que hagas un Proto-kanban, nunca obtendrás ningún valor.

Scrumban: Lo peor de lo peor, junto.

Cuando la gente me pregunta por Scrumban, siempre me temo lo peor. El caso genérico, con ciertas variaciones es:

“Scrum no funciona para nosotros porque no tenemos un producto, nosotros trabajamos por proyectos. El Product Owner es un Project Manager reconvertido que se encarga de hacer una lista de las cosas que hay que hacer. Además tenemos un SLA y salen un montón de bugs durante el Sprint que tenemos que arreglar, así que hemos incorporado un carril de urgentes en el Sprint Backlog en el que además de hacer los bugs, vamos metiendo lo que se la ha olvidado al Product Owner. Los Stakeholders no vienen a nuestras “demos” y las retrospectivas son para el equipo de desarrollo y para el Scrum Master.

Vemos que es muy difícil saber cuanto estimar en el Sprint Planning y las cosas no salen nunca, por eso empezamos a usar Scrumban.”

Esto no es Scrumban, no es Kanban y tampoco es Scrum.

Lamentablemente esta no es una situación que se arregle con ningún método ágil, así como ningún consultor o Scrum Master va a ser capaz de hacer nada por esta organización.

La solución

El primer paso para arreglar un problema es aceptar que existe un problema. Generalmente en este tipo de organizaciones tienen claro en todas las capas que las cosas van mal, pero hay poca voluntad de solución.

Los problemas aquí deben ser atacados desde la parte ejecutiva de la organización. De nada sirve que un equipo lo haga mejor si la cultura es: “Lo quiero, y lo quiero para ayer”.

Todo lo demás son castillos en el aire.