Scrum y Kanban

Scrum y Kanban

SCRUM es uno de los frameworks más utilizados en la industria del desarrollo de software y por años ha sido el punto de entrada de las organizaciones a la agilidad. Incluso en mi percepción esto le ha permitido casi que entregar una sensación de seguridad y control a nivel de directorios debido a que al utilizarlo gran parte de la industria ya se ha vuelto casi que un commodity y muchas veces comenzar a hacerlo ya no representa esta alta resistencia de la organización como si lo era en un principio, pero esa oportunidad también ha abierto otros puntos importantes que creo es importante ahondar.

Hace años atrás una de las cosas que más me quedó de mis entrenamientos en SCRUM es que este era un marco de trabajo y no una metodología o un método y que sobre esa premisa o aproximación había ciertas particularidades que presentaban muchas oportunidades y creo que esto ha caído en el olvido. En algunos entrenamientos SCRUM se me presentó como un paragua bajo el cual podrías albergar otras prácticas que podían permitirte potenciar o impulsar el uso de SCRUM. En otros, se me presentó como algo incompleto a propósito, algo como un contenedor que no prescribía al detalle que practicas o herramientas usar y que por lo tanto podía sumar las necesarias para poder reforzar los pilares de transparencia, inspección y adaptación.

Este enfoque de paraguas, contenedor o de incompletitud algunas veces queda como un punto ciego y hacemos SCRUM tal cual lo explican en las certificaciones o la literatura y olvidamos que parte de hacer SCRUM es experimentar y aprender a incorporar nuevas practicas que sirvan al equipo para mejorar la entregar de valor. Es sobre este punto donde conocí el termino del SCRUM Zoombie. El Scrum Zoombie se dice que nace y prospera cuando no hemos trabajado la transparencia como pilar para poder inspeccionar y adaptar adecuadamente.

Por ejemplo, el equipo SCRUM no tiene la más remota idea cuanto demora entregar un PBI o elemento del producto backlog o cuanto tiempo pasa desde que un stakeholder tiene una idea o deseo de funcionalidad hasta que esta es entregada al mismo. Es en este tipo de SCRUM  donde desde mi perspectiva nacen anti patrones como dailys con un enfoque de status, retrospectivas que terminan siendo un choque de opiniones o catarsis por que no existen datos a observar que nos puedan indicar que cosas sería bueno resolver y sin esa visibilidad terminamos también con discusiones por falta de colaboración, frustración por no entregar, exceso de trabajo en progreso, dependencias que no son visibles o cuellos de botella invisibles que no son resueltos y la causa raíz o impacto no es trabajada.

Mucho de lo que acabo de nombrar parte y nace como lo decíamos a través de una escases de transparencia para permitir la inspección. Por lo tanto, sin mayor transparencia al forzar una inspección terminamos teniendo instancias engañosas y de desperdicio donde muchas veces no se llega a nada. Y como resultado final de esto la adaptación da resultados de poco valor debido a los decisiones basadas en datos, información o suposiciones potencialmente inexactas.

Es aquí donde buscando algo que pudiera ayudarme con esto encontré Kanban. Uno de los primeros beneficios que pude obtener fue la visualización que refuerza mucho la transparencia en el equipo. El uso de tableros visuales para conocer el estado del trabajo en su flujo y medir su progreso son un pequeño gran paso que permite mejorar la inspección, reducir tiempos de coordinación y fomentar la comunicación y colaboración en los equipos. Todo tiene su complejidad y tiempo para poder trabajarlo, pero el beneficio obtenido vale totalmente la pena.

Pero esa visualización es solo un desde, transformar los eventos con prácticas de los feedback loops de Kanban, limitar el trabajo en progreso, apuntar a la mejora evolutiva y comenzar a utilizar las métricas de flujo propuestas por Kanban dentro de equipos SCRUM permiten poder salir de ese estado Zoombie.

Es importante destacar que desde el mismo Kanban no empuja a que deseches tu SCRUM, si no que lo ve como un paso importante y que a través de una mejora evolutiva comiences tal cuál estas con lo que haces ahora para recorrer un camino e ir introduciendo a los equipos de manera gradual lo que verdaderamente pueda entregar valor y resuelva dolores de los equipos.

Con esto te pregunto …

¿Cómo esta siendo tu SCRUM hoy? ¿Cómo es tu inspección? ¿Con que datos tus equipos toman decisiones?