Hace un rato en Twitter salió una polémica porque alguien mencionaba acerca de que SCRUM es más dañino que beneficioso y he aquí un RANT que aporta también el por qué estoy totalmente de acuerdo a empezar a quitar SCRUM de nuestras vidas (aunque suene repetitivo los puntos)
Lo primero es que SCRUM llegó a tener cierta idea que podríamos decir que ayudaría en el desarrollo, me quedaba pensando “venga esos dailies y compartir rápido si tenemos problemas y en qué andamos me da sentido, tener las tareas y asegurar tiempos, como que puede ser útil”, pero conforme fui avanzando en mi experiencia e introduciéndome más dentro de SCRUM me doy cuenta de lo equivocado que estaba.
Vamos a listar las 5 ceremonias de SCRUM y su tiempo aproximado:
- Sprint Planning: 4 a 8 horas aprox.
- Daily Scrum: 15 minutos aprox.
- Sprint Review: 2 a 3 horas aprox.
- Sprint Retrospective: 2 a 4 horas aprox.
- Sprint Grooming o Refinement: 2 horas aprox.
El sprint grooming/refinement no lo vamos a considerar, porque en realidad es algo que debe hacer “Producto” y no devs, no tendríamos mucha injerencia, pero quise compartirlo porque en sí es parte de SCRUM, aunque, en muchos lados SÍ hacen el grooming con los devs, solo en esta ceremonia lo voy a ignorar.
Ahora, ya tenemos más o menos cuánto dura cada cosa. Empecemos por el daily:
Muchas veces, el daily se hace por la mañana, otras por la tarde “antes de salir”, el que más tenía sentido era en la mañana, porque al final si tienes algo que te detiene, puedes compartirlo y durante el día se va desbloqueando eso para poder seguir avanzando… pero luego ves que compartes que algo te bloquea, el otro no hace nada y ahora imagina que lo compartes en la tarde, ¿te daría sentido que al día siguiente de eso se encargue quien te ayudaría no?, pues a veces no le hacen caso a tus “blockers” y deciden avanzar en lo suyo, presionas y siguen ignorándote. ¿Cuál fue el sentido del daily?… y peor “oh perdón se me olvidó que me dijiste X cosa”.
Desde algo tan simple, como el daily empiezas con conflictos, empiezas a gastar tiempo innecesario… Si dura aproximadamente 15 minutos, que es muy raro que en realidad haya Scrum Masters que te cancelen todo a los 15 minutos y si lo hacen, al final “el último ya no alcanzó a poner sus blockers, ahora tiene que ir a contactar a la persona directo” lo cual entonces, como decía, ¿para qué diablos quiero un daily si tengo que igual ir a mandar mensaje?…
15 minutos diarios * 5 días = 75 minutos * 4 veces al mes (aprox) = 300 minutos.
300 minutos que ya perdiste el tiempo haciendo dailies que estoy 99% seguro que si compartes por texto podrías: Resumir, queda evidencia real y es más directo. 5 horas perdidas del mes hasta aquí.
Vamos al sprint planning, básicamente el planning es una manera de que podamos saber qué tanto alcance vamos a tener en el sprint, es decir, en estas 2 semanas qué tantos tickets podemos resolver… de por sí la idea de hablar de tantos tecnisismos ridículos como “tickets/tareas/bugs/sprint/historias/blablablabla” es ya de por sí complejo, ahora tenemos que saber medir a través de ciertas reglas, que si usamos fibonacci, que si usamos no sé qué cosa para la dificultad, que tenemos 40 puntos en el sprint, que si jugamos póker que no es póker…
Entonces el planning al final del día es un “pregúntale a los devs qué tan complicado es esto, qué tanto pueden hacer y si no entregan lo que se comprometen los voy a cagar porque se comprometieron y no me cumplieron”, ahí como digo son normalmente 4 a 8 horas, vamos a dejar una macro llamada que los devs aman las macro llamadas de 6 horas aproximadamente para un sprint de 2 semanas (sí, 2 semanas)… si consideramos 6 horas * 2 sprints al mes = 12 horas.
Antes de saltar a la siguiente ceremonia me gustaría agregar que si simplemente se dejaran los tickets como tickets (es decir, sean tareas, bugs, historias, actividades, lo que sea) y únicamente producto los va poniendo en orden de prioridad, bien podríamos estar tomando tickets, sacando tickets, tomando tickets, sacando tickets, algo así como un bello Kanban sencillito, facilito y todo se movería más ágil (¿irónico no?)
Bueno, ahora sí, ya tenemos un planning donde hasta este punto vamos a perder 17 horas al mes aproximadamente, vámonos al review, el review se hace normalmente con los stakeholders, los devs no deberían hipotéticamente perder el tiempo aquí, pero como dije, solo quité el grooming porque en todos lados donde me ha tocado, a menos que el tech lead/dev lead/PM/scrum master/PO y demás “de arriba” sean buena onda, te hacen entrar… en mi caso como Tech Lead siempre evito que los devs entren ahí, pero mi compañero de trabajo los mete… entonces, vamos a considerar que sí entran porque son bien ojetes la mayoría.
Ya que me quejé de eso, el review es meramente decirle a los stakeholders “al chile no cumplimos con la meta, se quedaron tickets atrás y el release del viernes tuvo que ser rollback” (o bueno no necesariamente eso si no un resumen de lo que pasó en el sprint, pero es lo más común que sucede(?))… Los stakeholders bien podrían recibir del PM ese reporte reseñado lo más posible y no importarles por qué diablos el Dev Juanito Pérez no libró el ticket fulano porque no le entregaron X cosa y en los dailies la QA Margarita Gonzáles se le olvidó compartirle el cómo reproducir bien el issue…
En fin, vamos a pensar que esta son 2 horas más… 2 horas + 17 horas que ya llevamos perdidas, son 19 horas, 19 horas en 1 mes que ya se perdieron en juntas.
Vamos a las retro, las retros es una forma de quejarse que X persona no cumplió con sus cosas, que Y se nos retrasó por culpa de otro, que alguien sacó las cocas y eso estuvo bien y cómo diablos planeamos mejorar el próximo sprint que igual no cumpliremos pero diremos que sí… en otras palabras, una forma de sacarse de encima lo bueno, lo malo y no hacer nada al final del día.
Y esto es una realidad, donde puede causar más conflictos internos que ayudas, no ayuda al proyecto en realidad, si algo sale mal en un sprint, entonces no es culpa de uno es culpa de todos y está bien “dar retro para ver qué se puede hacer” pero esas cosas deberían hacerse casi al momento y estar siendo llevadas por los líderes, los devs no deberían estar acomplejándose porque Fulanito no hizo su chamba bien y entonces empezar a agarrarse odio, y al final de las retros casi siempre le agregan los “agradecimientos” pero en mi caso he visto que ni si quiera le agradecen a todos, y le agradecen bien “escuetamente” causando que te de cierto coraje tipo:
Angelita fue super buena onda, me ayudó un montón en este sprint, gracias a ella me desbloquee del ticket y bla bla bla bla * frases bonitas * * más frases bonitas *
Y Angelita como de “no le voy a poner nada, me quitó mi tiempo” y si te ponen algo al final es un “Antonio me dijo gracias” y ya una tontería así…y te da coraje cómo tu sí eres agradecido y el equipo hacia ti no te da nada… y lo he notado en mis equipos cómo de “no me dijo nada, en el próximo retro me vengo y no le pongo nada” y sí termina por suceder eso. Por lo que a mi parecer, esas retros son pésimas y yo obligarlos a poner algo tampoco lo considero, pero recordemos, yo NO soy PM/SM ni nada de eso así que … ¯\_(ツ)_/¯
Las retros tardan de 2 a 4 horas aproximadamente, vamos a considerar 3, son 19 horas que llevábamos + 3 horas ahora, 22…
Entonces, ya tenemos las 4 ceremonias cubiertas (o “5”) e hicimos un total de 22 horas, cuando trabajamos en proyectos, siempre debemos considerar, SIEMPRE, a menos claro que la empresa donde trabajas sea un asco (que el 99% lo son) un horario productivo, es decir, la realidad donde sí trabajas, por ejemplo:
Durante el día vamos al baño, vemos unos memazos, respondemos y revisamos correos, checamos pendientes, checamos mensajes de los jefes, etc… perdemos aproximadamente 2 horas de las 8 laborales regulares, entonces, ¿eso en qué termina?… en que si tenemos 1 mes, vamos a escoger, Junio (solo porque tiene 30 días, y no tiene días feriados) 2024, tiene 10 días de fin de semana, entonces son 20 días, 20 días de los cuales se trabajan 8 (no se considera la hora de comida) pero como dijimos, son 6 horas productivas, 2 que se queman en actividades varias.
Si tenemos 6 horas productivas, en 20 días, son 120 horas productivas en un mes, a eso le vamos a quitar 22 horas de SCRUM, hermoso y bello SCRUM, son entonces 98 horas reales que vamos a trabajar…
Si a esas 98 horas reales, porque interrupciones para responder y demás podrían irse en no productivas, le intentamos asignar tiempos, tickets, ¿qué tanto podemos en realidad trabajar?, 98 horas en un mes donde si trabajáramos sin SCRUM y a través de tickets que entran y salen, si se quitaran de encima esos “¿Cómo vamos?” de los PMs, si los clientes dejaran de estar de encimosos haciendo preguntas innecesarias, si los equipos confiaran en sus compañeros y no tuvieran que estar tras de ellos, podrían incrementar muchísimo y hacer que de 20 días, tengamos unas 140 horas productivas al subir de 6 a 7 productivas (aún considerando el tomar agua e ir al baño) y no tener SCRUM ni nada así…
Entonces, ¿por qué diablos las empresas siguen ofreciendo SCRUM como “lo máximo”? porque les hacen creer a los clientes que tienen el control, porque cobran por hora, porque los clientes se sienten integrados, porque mil cosas que casi ninguna (excepto cobrar por hora, ¿a quién no le gusta estar viendo a alguien hablar de la review mientras en realidad está en una partida de TFT sabiendo que no debe hablar así que ni se preocupa?…
Pero al final esto se hace muy cansado, estresado, complicado para los programadores… así que ya saben, si son líderes, si son clientes, si son lo que sean, empiecen a quitar SCRUM y a subir la productividad 😉 … por un mundo mejor sin SCRUM
