Hace una semana se popularizó un tweet acerca de Scrum y su mala fama. El autor del Tweet no se andaba con segunda y califica a Scrum como cáncer. Además, exponía una serie de argumentos para apoyar esta afirmación tan dura y categórica.
Vamos a analizar todos los argumentos que Santiago expone y explicamos cada uno de ellos para entender su postura. ¡Vamos con ello!
1. Trataron de convencerme de que el Poker era una herramienta de planificación en vez de un juego
Esta afirmación es cierta, el Planning Poker es una técnica que tiene beneficios pero siempre que vivamos en el paradigma de ser predecible a base de estimaciones. El Planning Poker fomenta la comunicación pero puede convertirse en una herramienta muy pesada si la usamos para estimar una gran cantidad de items del Backlog.
Sin embargo, Scrum está fuera de esta técnica, de hecho se ha eliminado la palabra “estimar” de Scrum. Las estimaciones son lo contrario a la agilidad donde buscamos tomar decisiones en base a números que, por desgracia, nos inventamos.
Negar Scrum por una técnica de la que Scrum ni habla, no me parece correcto.
2. Si quieres ser más eficiente, debes agregar procesos, no eliminarlos. Nos hicieron asistir a las “ceremonias”, un nombre elegante para un montón de reuniones: stand-ups, refinamientos, planificación, retrospectivas y Scrum of Scrums. Pasamos más tiempo hablando que haciendo.
Estoy muy de acuerdo con Santiago en el que, añadir más reuniones (con nombres guays) puede ser una pésima idea en muchas empresas. ¡Bastante saturados está ya el calendario de reuniones!
De las reuniones que comenta Santiago, varias de ellas no tienen nada que ver con Scrum: stand-ups no existen, los refinamientos son opcionales, y Scrum of Scrums no es parte de Scrum.
Scrum propone que elimines reuniones a cambio de sus eventos, se supone que deberían ser suficientes. Evidentemente, depende de la implementación que haga cada equipo o cada empresa. Ahora bien, si Scrum se conviert een “añadir nuevas reuniones” es normal que genere rechazo.
Aquí vemos un patrón claro, el Scrum de las empresas es muy diferente al Scrum propuesto y esto está generando una disyuntiva clara que puede convertir a Scrum en un infierno para el desarrollo de software.
3. Prohibimos las computadoras portátiles en las reuniones. Tuvimos que ponernos de pie. Nos pasamos una pelota para que todos prestaran atención.
Esto es un ejemplo de un Scrum poco profesional y bastante ridículo. Si estamos usando Scrum para desarrollar software disponer de ordenadores es clave. De hecho, deberíamos incluso revisar código en una Sprint Planning para poder tener conversaciones basadas en nuestro producto y no en fantasías.
Lo de “pasar una pelota” es una manera de ridiculizar una práctica habitual en muchos equipos. Obviamente, el autor intenta ridiculizar Scrum asociándolo a una práctica. Ahora bien, muchos equipos tienen problemas de comunicación y pueden necesitar de alguna herramienta que les ayude.
4. Pasamos más tiempo estimando los puntos de la historia que escribiendo software. Los puntos de la historia miden la complejidad, no el tiempo, pero tuvimos que decidir cuántos puntos de la historia caben en un sprint.
Los puntos de historia vienen de eXtreme programming y no de Scrum. Sí, hemos aprendido en Agile que los Puntos de Historia no son ágiles porque buscan la predictibilidad por encima de la adaptabilidad.
Podemos debatir si los puntos de historia son buena técnica pero, desde luego, buscar mejores maneras de estimar está muy alejado de Scrum y del Manifiesto Agile.
Además, cuando pasamos más tiempos haciendo estimaciones que trabajando desarrollando software es una prueba irrefutable de que nadie quiere trabajar en un equipo así. Pero, una vez más, Scrum eliminó la palabra “estimar” de su propuesta, entre otras cosas, por este tipo de situaciones.
5. Tuve que usar tallas de camisetas para estimar el software
Usar tallas de camiseta es otra práctica habitual en muchos equipos que se definen como ágiles. En mi opinión, es una técnica sencilla que permite comprar items de cara a ordenarlos por tamaño (sizing) y puede ayudar. Ahora bien, insistimos, Scrum no dice nada de estimaciones.
Recordemos que casi toda la propuesta de Scrum se basa en la idea de entregar (delivery). Cuando un equipo entrega, Scrum hace su magia, y eso es lo que realmente le importa a un Scrum Team.
6. Medimos cuánto costaba entregar un punto de la historia y luego redactamos contratos en los que los clientes pagaban por un paquete de “500 puntos de la historia”.
Los contratos ágiles son una asignatura pendiente para muchos equipos y empresas. Sí, existen ventas por “paquetes de puntos”. Ahora bien, cuando se realiza algo así, generalmente es debido a que es un “paquete abierto” donde el Scrum Team y la empresa cliente dejan el alcance abierto y disponen de un grado de confianza muy elevado.
Recordemos que Scrum no está pensado para equipos de consultoría que trabajan para terceros. Esa dependencia cliente-proveedor es un gran obstáculo para realizar productos orientados por valor. Hay mil propuestas sobre cómo mejorar esta relación y, en muchos casos, se convierte en situaciones duras para los Developers. Scrum busca desarrollar los mejores productos para resolver problemas complejos en vez de adaptarse a un proveedor para que el cliente “compre Scrum”.
7. La gerencia se perdió cuando descubrió que 500 puntos de historia en un proyecto no eran lo mismo que 500 puntos de historia en otro proyecto. Tuvimos muchas reuniones para solucionar este problema.
Los puntos de historia nacieron de la agilidad pero, con el tiempo, se han demostrado poco ágiles. Muchas empresas que usan puntos de historia lo hacen impuestos por la gerencia, que sigue pensando en predecir en base a estimaciones. Esta cultura tradicional-predictiva genera muchas situaciones incómodas. Una de ellas, es la ausencia de comparación entre equipos que muchas empresas valoran.
El problema de esta comparación no son los puntos de historia. El gran reto es entender que cada equipo está resolviendo problemas diferentes y que, al estar en entornos complejos, es absurdo comparar equipos. Si un equipo de científicos está desarrollando una cura para el Covid y otro para el Alzheimer, ¿cuál trabaja mejor? ¿cuál hace mejores ensayos? ¡Estamos comparando equipos que trabajan de maneras diferentes!
Podemos concluir que, los puntos de historia son un cáncer y no Scrum ya que, como hemos comentado antes, Scrum no propone estimar nada.
8. Imagine tener un gerente, un scrum master, un propietario de producto y un líder tecnológico. Había que responder a todos y a ninguno simultáneamente.
Scrum elimino el concepto de rol en la última versión (2020). El Product Owner busca maximizar el Producto y el Scrum Master que el equipo se oriente a valor y funcione. No existe el concepto de Líder Técnico con lo que, ya perdemos una “figura de reporte”.
Estoy de acuerdo en que, estar reportando a dos figuras es cansado, absurdo y un impedimento claro. Pero, un Scrum Team es autogestionado, debería evitar ese reporte contínuo salvo que estuviera justificado. Por ejemplo, si el Scrum Master está trabajando con la organización para que las personas expertas en QA pertenezcan al equipo y no a otro departamento, puede ser interesante que los Developers le cuenten si está funcionando la entrada de personas en el equipo.
9. Pagamos a personas que nos decían si estábamos “quemando puntos” lo suficientemente rápido. ¿No se trataba de puntos de la historia sobre complejidad en lugar de tiempo? No importa.
El Burndown Chart es una herramienta que sí aparece en Scrum como opcional. De todos los argumentos este es el único que sí está alineado a Scrum. Sin embargo, la situación que describe está muy alejada de la propuesta del marco de trabajo.
Lo primero de todo, tener personas que controlen a los equipos a nivel de puntos suele ser terrorífico. Este tipo de situaciones nos llevan a conversaciones donde importan más los puntos que las personas y, peor aún, el trabajo realizado (delivery).
Los puntos de historia deberían representar “cantidad de trabajo” en vez de complejidad. Ahora bien, por encima de la cantidad de trabajo que un equipo genere, es más relevante la entrega (delivery) y sobre todo, el valor que dicha entrega provoca (resultados).
Scrum es un cáncer
Santiago, el autor del tweet, finaliza sus conclusiones con esta reflexión:
“Creo en Agile, pero esto no es ágil.
Trajimos entrenadores profesionales de Scrum. Pagamos a personas de nuestro equipo para obtener la certificación. Probamos Scrum de esta manera y de otra. Pasamos años haciéndolo. El resultado era siempre el mismo: no funcionó.
Scrum es un cáncer que se comerá a tu equipo de desarrollo.
Scrum no es para desarrolladores; es otra herramienta para que los gerentes sientan que tienen el control. Pero lo mejor de Scrum son aquellos que te miran a los ojos y te dicen: “Si no te funciona, lo estás haciendo mal. Scrum es cualquier cosa que funcione para tu equipo”.
Entiendo que defender Scrum a capa y espada como si fuera una “religión” perfecta es un grave error del mercado. Pero, es importante que los argumentos que desarrollemos sean orientados a Scrum y no a malas experiencias implantando prácticas de dudosa utilidad en nombre de Scrum. El famoso dicho “si no sabes, para qué opinan”.
Ahora bien, hay una realidad que no podemos ignorar. Existe una enorme distancia entre la propuesta de Scrum y el Scrum que encontramos en las empresas. Esta realidad es lo que denomino “Scrum Profesional”. La realidad de muchas organizaciones es que acaban viviendo un Scrum que, lejos de ayudar, se convierte en un obstáculo para las personas.
Scrum se ha dejado llevar por la moda y por la venta de certificaciones al peso. Tal es así, que existen muchas empresas que venden Scrum como si fueran caramelos en vez de trabajar por conseguir equipos orientados a valor (de negocio).
Y tú, ¿qué opinas de Scrum?
Por cierto, mis respeto a todas las personas que han sufrido un cáncer en primera persona o algún familiar.
Aquí está el tweet original:
Hola Javier
Buenas
Me quedo con la ultima parte, si es verdad hay empresas que venden el programa solo con el afán de que te certifiques y después aprendas a usar este framework, lo digo por que estuve en un programa hace unos meses de dos docentes donde estudie un máster, y solo repetían el programa esta hecho para que consigan el certificado y el nombre del fundador como para darle peso, y preguntas solo las especificas por que el tiempo es limitado, después en la practica entenderán.
Personalmente creo que es una herramienta poderosa pero de esta forma como lo están enseñando terminas desmotivado.
Saludos
Daniel
Leí el artículo original cuando fue publicado. Y al acabar de leerlo, salvo tal vez el último párrafo, estaba convencido de que estaba escrito como un gran sarcasmo. Justo por los puntos que mencionas y (al menos a los que. vivimos en este medio) que nos resultan fáciles de replicar, creo que era una forma donde sarcásticamente, tomaba “scrum” o “agilidad” por un montón de prácticas sin contexto.