Personalmente trabajé previamente en ambas metodologías “ágiles”, e irónicamente, considero que Scrum es poco ágil y lento, más para un ambiente startup donde constantemente se esta buscando un product market fit y las prioridades pueden cambiar de un momento a otro.

Desde mi perspectiva, Scrum, con todas sus ceremonias, reglas, compromisos de tiempo, y estimaciones y métricas basadas en story points son, en muchos casos, una pérdida de tiempo. Tantas ceremonias rayan en la “reunionitis”, y los story points son una métrica altamente subjetiva sacada del culo, que nadie hace de la misma manera. Ambas cosas solo buscan dar una sensación de control para un proceso que, por naturaleza, es altamente complejo y caótico, el cual llamamos, desarrollo de software.

El que hoy en día te diga que puede estimar con alto grado de certeza, cuánto tiempo se va a demorar algo y con que complicaciones se va a encontrar, en el ámbito del desarrollo de software, te esta mintiendo. Las estimaciones más acertadas siempre se basan en la experiencia de quien estima y quien desarrolla, que además no siempre son la misma persona, y en el mejor de los casos, son sólo eso, estimaciones, difícilmente se pueden considerar ejercicios sistemáticos altamente precisos.

Dicho en palabras más sencillas, usar scrum (al pie de la letra) es nadar contra la corriente y la naturaleza de lo que hacemos como ingenieros de software, no hay nada más agotador.

Kanban, en su lugar, busca nadar a favor de la corriente. ¿Si estimar tiempos acertados es casi imposible, por qué pierdes tu tiempo con eso?, si la prioridades van a estar en constante cambio, ¿por qué forzarlas a compromisos de tiempos y castigar si esos compromisos no se cumplen?.

Kanban propone una premisa mucho más simple, “just get shit done”. Define cuales son tus prioridades hoy, ponlas en un lista de “tareas”, define el flujo de trabajo que lleva esa tareas de principio a fin, y ponte a trabajar.

Si las prioridades cambian, solo cambia su posición en la lista de tareas, y la primera persona del equipo que termine la tarea en la cual esta trabajando, toma la primera tarea pendiente de la lista, sin drama.

Si la totalidad de un feature ya fue terminado, sencillamente pasas al siguiente de la lista, sin perder horas en sprint retro, sprint demo, sprint planning, sprint grooming, o esperar a que inicie el próximo sprint.

Kanban, en resumen, convierte el desarrollo de software en una línea de producción que busca entregar valor constantemente, idealmente, todos los días.

Ahora, lograr que esto funcione es difícil. El equipo tiene que ser altamente independiente, la comunicación constante es sumamente importante, y hay un peso grande en los product owners, managers y líderes técnicos, por mantener el to-do-list priorizado y refinado. Pero si lo logras, el equipo se vuelve altamente eficiente y es capaz de entregar valor casi que diario.

Quizas se esten preguntando, “Profe, pero que locura, si todo cambia todo el tiempo, ¿como vamos a lograr terminar algo, que pasa con la retroalimentación del equipo, como sabemos a donde vamos, y cuando vamos entregar el feature que nos va a cambiar la vida?”, Intro Muni Scrumban.

En Muni decidimos tomar las características de Scrum y Kanban que más nos hacían sentido, y construimos nuestro propio marco de trabajo.

En esencia, muestra principal metodología era Kanban, pero con algunas ceremonias y procesos muy cercanos a Scrum.

Hacíamos daily stand ups para vernos las caras, generar algo de empatía, comunicar progresos, blockers, y levantar alertas o comunicar cambios de prioridades.

Si bien estábamos abiertos al cambio de prioridades, cuando esto es constante y todos los días, afecta el rendimiento y moral de cualquier equipo y persona, por ende teníamos sesiones semanales de refinamiento entre producto y tecnología, para verificar en que vamos, que se viene, agregar eso a la lista, y si DE VERDAD, vale la pena algún cambio de prioridad.

Es importante resaltar que no todo el equipo era necesario para estas sesiones, y era una de las principales responsabilidades de los product owners, líderes técnicos y  managers.

También hacíamos sesiones de retrospectiva cada dos semanas aproximadamente, o cuando cada equipo lo considerara necesario. Pero no como obligación o religión, tampoco al finalizar cada feature. Estas eran sesiones eran un poco más catárticas, donde podíamos expresamos cualquier cosa, y acordar algunas soluciones cuando hacía sentido.

Finalmente, sobre saber que nuevos desarrollos se vienen, y cuanto tiempo se van a demorar, es otro tema aparte que dejó para la sección de “¿Cómo definimos nuevos features o productos?”