Scrum es un cáncer.
Empieza bien, empieza bien la cosa.
Haciendo amigos, vamos a hacer amigos, venga.
He estado escribiendo software durante 25 años y nada inutiliza a un equipo de software como lo hace Scrum.
Algunas anécdotas intentaron convencerme de que el póker es una herramienta de planificación, no un juego.
La verdad es que este punto me parece un poco infantil, pero bueno, no pasa nada.
Dos, 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.
Entonces, stand-ups, arreglos, planificaciones, retros, scrum of scrums.
Pasamos más tiempo hablando que haciendo.
¡Ojo! Más hablando que haciendo.
Muy de acuerdo. ¿Os pasa?
Uno de los problemas, que no sé si es culpa de Scrum o de la gente o del Scrum que estamos haciendo, ¿no?
Muchas reuniones estrés. La verdad es que demasiadas reuniones.
El tema, no sé si es un tema de echarle la culpa a Scrum, que al final no deja de ser un framework.
O si es un problema de las empresas, de la cultura de las empresas, de la gente que quiere reunirse.
Yo qué sé, tío. No sé, no sé. No sé de quién es la culpa.
Pero es una locura, ¿eh?
El otro día me contactaba un chico por LinkedIn y me decía
Oye, Midu, esto es normal. Y me pasaba su calendario.
Y tenía como 15 reuniones en una semana.
15 reuniones que dices.
Esos son dos reuniones al día, más las dailies, que son diarias.
Madre mía.
Tres, prohibimos las computadoras portátiles en las reuniones.
Tuvimos que ponernos de pie.
Nos pasamos una pelota para que todos presten atención.
Ay, qué risa, ¿eh?
Qué risa eso.
Algunas ceremonias de estas de...
No, venga, pasar la pelota.
Nos tiramos la pelota.
Lo que me da un poco de miedo de estas cosas es intentar de forma artificial hacer entretenidas las cosas
porque de facto son aburridas.
Eso es una mierda, ¿sabes?
El tener que...
No, vamos a intentar que sean interesantes poniendo una pelota de rugby que nos tenemos que tirar.
Y dices, hostia, no, qué mierda.
¿Sabes? O sea, ¿qué significa?
Que va a ser esto una muerte en vida esta reunión.
Tuve que usar tallas de camisetas para estimar software.
Hostia, esto siempre yo personalmente lo he odiado.
Estimar como tallas de camisetas, puntos de esfuerzo...
Siempre, siempre, siempre me ha parecido bastante ñe.
Porque lo importante, lo más interesante muchas veces sería más el hecho de...
Oye, a lo mejor lo que tenemos que hacer es hacer tareas más atómicas que nos acerquen, que sea valor directamente, ¿no?
Yo creo que en gran medida el éxito de las grandes empresas es el buen uso de esas metodologías, pero usarlas no es fácil.
Y ahí es donde vienen los problemas.
¿Tú crees que en gran medida el éxito de las grandes empresas es el buen uso de las metodologías?
¿O es pese al uso de estas metodologías?
Porque yo creo que muchas veces hay empresas inoperantes.
Ah, punto 4, que me lo he saltado.
Pasamos más tiempo estimando los puntos de la historia que escribiendo software.
Hostia, esto es verdad, ¿eh?
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.
Voy a decir, es que me sabe mal porque son cosas un poco polémicas, ¿vale?
A ver, ¿de dónde viene todo el tema de Scrum?
Mucha gente se cree que viene sobre el agilismo, pero de dónde viene realmente todo esto es en medir la productividad del desarrollador.
Y eso es muy peligroso.
Esa es la realidad desgraciada de donde vienen muchas de estas metodologías y muchas métricas que se intentan imponer porque lo que se quiere es medir la productividad de las personas.
Como si fuese una fábrica y lo que quieren es saber la productividad de si estás rindiendo o no estás rindiendo, si vas rápido o vas lento, si todo esto, ¿no?
Y eso es lo que realmente da pena porque no es tanto que le interese como que sea ágil porque al final se hacen muchos procesos waterfall que están enmascarados.
Si no sabéis lo que es waterfall, búscalo en Google.
Están enmascarados porque al final tienes fechas de entrega, cuándo tienen que estar las cosas y da bastante pena.
¿Y por qué estoy seguro de lo que digo?
¿Y por qué lo digo?
No solo por mi experiencia, sino porque muchas veces lo dicen y te lo dicen en la cara.
Aquí tenéis esta consultora que es McKenzie que tiene un título que dice, sí, podemos medir la productividad del desarrollador.
Software Developer Productivity.
O sea, no de la productividad como empresa, sino del desarrollador.
Podemos medir la productividad del software developer, no de development.
Podemos medir, trackear y hacer un benchmarking de la productividad del desarrollador.
Siempre ha sido considerado un black box y no tiene por qué ser así.
Este artículo es un artículo muy interesante de McKenzie y para que os hagáis una idea,
McKenzie es una de las grandes consultoras que muchas, muchas, muchas organizaciones y empresas grandes
la utilizan para tomar decisiones muy importantes.
Sí, lo hacen como si fuésemos máquinas.
Y el tema es que no estoy nada de acuerdo con las cosas, muchas de las cosas que hablan por aquí.
Sí que estoy de acuerdo con otras, que la verdad es que hay otras cosas que sí que son interesantes,
pero no tanto en cuanto a enviar ese mensaje de la productividad del desarrollador.
Porque hay que evitar, al final si tú pones métricas, lo que se hace normalmente históricamente es optimizar para esas métricas.
Y entonces puede ser un problema, aunque las métricas son importantes.
O sea, es importante saber cuánto tiempo se tarda en subir un back, una feature, cuántos deploys se hacen a la semana,
cuánto tiempo tarda ese deploy.
Hay que tener métricas, las métricas son súper importantes.
Y obviamente alguien me preguntaba, ¿y tú qué harías?
Yo la verdad que lo que haría, en muchos casos, yo no utilizaría Scrum, a mí nunca me ha gustado,
porque no es tanto una metodología de desarrollo de software, sino de desarrollo de proyectos.
Y yo creo que en desarrollo de software, Extreme Programming, incluso Kanban, me parecen mejores.
Muchas veces, muchas de las liturgias, ceremonias que se hacen, se pueden hacer realmente,
no como reuniones, sino como pre-programming, como cosas más activas del desarrollo de software.
Por ejemplo, si en lugar de dailies, la gente hiciese mob programming, o sea, que todo el mundo programase juntos una hora al día,
ya se pondrían al día de un montón de cosas y problemáticas que tendrían.
Y el problema es cuando se pervierten, o sea, debe haber una comunicación constante.
El tema de que en las dailies, no, es por si tiene bloqueos y tal, pero es que eso no debería esperar a una daily y este tipo de cosas.
No sé, a mí todo el tema de liturgias, el tema de las retros, por ejemplo,
me gusta mucho más el feedback directo y no tener que esperar y aguantar una semana, dos semanas para decir algo a alguien.
El tema de no esperar a una ceremonia y el hecho de que la gente se comunique.
El problema es que muchas de estas ceremonias es para lidiar con el tema de que la gente no se sabe comunicar
o tiene miedo al feedback.
Y yo creo que esas cosas son muy importantes.
Son importantes realmente saber trabajar en equipo y que haya una comunicación directa y fluida.
Scrum tiene buenas intenciones para que nadie lo usa bien.
En eso voy a estar bastante de acuerdo porque la verdad es que Scrum, el Scrum que se utiliza hoy en día en las empresas,
no es el Scrum real que en su día se imagina.
En fin, más cositas.
6. Medimos cuánto costaba entregar un punto de historia, luego redactamos contratos de que los clientes nos pagaban
por un paquete de 500 puntos de la historia.
Sí, la verdad es que tela, ¿no?
También la velocidad, ¿no?
Me encanta que mucha gente quería medir la velocidad del desarrollo para saber cuántos puntos de historia
se podían sacar a la semana, cosas así.
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 ninguno simultáneamente.
Esto también es una cosa que da bastante penilla.
El hecho de que son un equipo a lo mejor de 7, hay 3 desarrolladores y hay que reportar a 4 personas.
Al Product Owner, al Scrum Master, al Team Lead, al no sé qué.
Y hay 4 desarrolladores.
Y dices, joder, es que a lo mejor nos sobran leads aquí o gente a la que hay que darle explicaciones.
Y te viene y te está haciendo un sándwich donde tienes el Scrum.
Oye, ¿por qué esta tarea no la están moviendo?
No sé qué.
Pero, oye, tú estimaste esto como 3 puntos y ya llevas 3 días.
Y dices, oye, ¿pero no me dijiste que esto no era tiempo?
Bueno, he visto, hay muchas historias de terrores con esto, ¿eh?
Pagamos a personas que nos decían si estábamos quemando puntos lo suficientemente rápido, joder.
¿No se trataba de puntos de la historia sobre complejidad en lugar de tiempo?
No importa.
La verdad, este es el error más grande que normalmente he visto, ¿no?
El tema es que es una cosa muy perversa, el tema de los puntos que dicen que no es tiempo.
Pero cuando por lo que sea, esos puntos que tú habías dicho, oye, esta tarea es un 3 y resulta que tardas más tiempo.
Entonces viene que tienes que dar explicaciones, ¿no?
Y, oye, ¿pero por qué tardaste 3 días?
Oye, pues porque se complicó.
Ah, no, pero claro, le habíamos puesto...
Y dices, madre mía, para mí un punto es un día.
Claro, pero entonces, ¿ves?
Ya estás haciendo como...
Es como...
No tiene sentido.
No tiene sentido porque entonces ya estás haciendo una traducción, básicamente.
Creo en Agile, pero esto no es ágil.
Obviamente esto no es ágil.
De hecho, esto es como un waterfall encubierto.
El resultado de siempre el mismo.
No funcionó.
Scrum es un cáncer que se comerá 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.
Ay, ¿eso es verdad?
¿Eso es verdad?
¿Verdad total?
¿Eso es verdad total?
Que yo siempre, siempre que a lo mejor he dado feedback sobre Scrum, dice, es que no estás haciendo bien Scrum, es que no sé qué.
Y es lo más repetido siempre, ¿no?
Es que no estás haciendo bien Scrum o es que tienes que quitar las cosas de Scrum que no te sirvan.
Bueno, claro, si quitas todas las cosas malas de Scrum, ya no haces Scrum, a lo mejor estás haciendo otras cosas, ¿no?
Mejor sería capacitar al equipo en comunicaciones of skills y evitar tantas reuniones innecesarias.
Estoy totalmente de acuerdo.
A ver, yo creo que Scrum, la idea original, obviamente era positiva y es un framework que se utiliza para intentar desarrollar proyectos de forma ágil.
O sea, está bien, no iba con mala...
Su idea original nunca fue negativa, pero creo que obviamente mucha gente se ha tenido que enfrentar a un Scrum que no tiene nada que ver.
Porque al final lo que ha pasado es que es una forma de controlar a los desarrolladores, intentar calcular qué es lo que hacen.
Hay gente que se cree que Scrum es tener las tareas en un dashboard, que es hacer retros, cosas así, ¿no?
Y es bastante...
¿Existe algún framework Agile que sea como indicado para el desarrollo de software?
A ver, el más parecido como framework Agile que podríamos indicar...
Porque el Agile no es un framework y no recomienda ninguno.
Es un manifiesto que tiene como diferentes puntos y tal y son 12 principios.
Bueno, los principios en general hablan de mejor comunicación por delante de las personas y que el software trabajando es la mejor medida de progreso.
Entonces, hay muchas veces que estos consejos de manifesto chocan totalmente con un montón de frameworks como, yo que sé, como Scrum, ¿no?
Pero aún así, pues, Extreme Programming sí que es algo que está pensado más para el desarrollo de software y que estaría más cerca seguramente a la metodología Agile.
Just do it.
Ese también es una bastante buena.
Just do it.
Hazlo y punto.
Eso es lo que tienes que hacer.
Suena a explotación.
No, pero en realidad Extreme Programming lo que viene a hablarte es más de P-Programming, de cómo evitarte muchas de las ceremonias y asegurarte que estás haciendo software de calidad y de forma sostenible en el tiempo, lo cual es bastante interesante.
Yo siempre que me programan algo, dice Gatuno de Tuno, respondo personas sobre procesos.
Es lo único que me ha quedado en el cerebro.
Personas sobre procesos es justamente uno de los puntos del manifiesto Agile.
Y ya veis que muchas veces muchos frameworks son muchos procesos encima de las personas.
Para que funcione una empresa correctamente no se necesitan ceremonias, se necesita comunicación.
Y por desgracia esto suele tardar bastante, ¿no?
Empresas grandes como Spotify no utilizan Scrum.
Bueno, esto es lo típico, ¿no?
Pero tampoco, eso es muy importante.
Mira, os voy a comentar otro tema que es bastante importante.
Hay un problema de base en muchas empresas de desarrollo de software.
Por ejemplo, en la última empresa en la que yo estuve, una cosa que hacían era fijarse mucho en lo que hacía Spotify.
Decía, es que Spotify está organizado en enjambres y entonces no hacen Scrum, hacen tal.
Y es un error de bulto intentar apropiarte de las metodologías que utiliza una empresa.
El copy-paste de metodologías difícilmente funciona porque es otra cultura de empresa.
Otra cultura de dónde está la oficina.
El producto no es exactamente el mismo.
Es un error que yo he visto cometer este error así de veces.
De decir, bueno, como hace Spotify, vamos a hacerlo.
Y un montón de empresas se lanzan ahí al vacío que dices, no tiene sentido.
Y eso lo he visto yo en mis 15 años, lo he visto constantemente.
Cuando dices, es que ni siquiera el objetivo de la empresa es el mismo.
Porque a lo mejor el objetivo de una empresa, por ejemplo, Instagram, el objetivo que tenía la empresa era crecer para ser comprada.
Hay otras empresas que su objetivo es hacer dinero.
Pero son cosas totalmente distintas de objetivo de empresa.
Y por lo tanto, la metodología puede ser diatralmente distinta.
No pueden ser ni parecidas.
Así que uno de los problemas de Scrum es justamente el hecho de intentar que todos los equipos tengan la misma metodología.
A mí me parece un error, pero bueno, aquí cada uno que opine lo que quiera.
El hecho de forzar que todos los equipos tengan que trabajar exactamente igual, con el mismo proceso, para mí es un error.
Yo lo que haría es que todos los equipos puedan decidir.
Oye, ¿funcionáis mejor con GitHub Projects?
¿Funcionáis mejor no sé qué?
¿Tú quieres utilizar Kanban?
¿Quieres utilizar Scrum?
¿Quieres utilizar Stream Programming?
Está súper bien que compartan lo que habéis aprendido, vuestros resultados.
O va bien o va mal.
Pero el instaurar una metodología, normalmente, yo siempre he visto que no funciona.
A mí me parece un error.
Porque al final no es ágil.
Forzar una metodología es como todo lo contrario a ser ágil.
Estás forzando ya como unos mimbres en los que tienes que moverte.
Eso no es ágil.
Eso es justamente ser estático.
¡Gracias!