Scrum

Marina d’or no es un balneario y tu equipo no es Scrum

Estaba viendo las noticias y aparece una muy curiosa “Marina D’Or ha sido demandada por venderse como balneario cuando no tiene aguas medicinales”. Esta noticia que podéis leer aquí me ha recordado mucho a Scrum. Resulta que la asociación de Balnearios ha denunciado porque Marina d’or se promociona como balneario y no cumple las normas para serlo. El final de la noticia era curioso, la empresa afirmaba “somos balneario porque para ser un balneario no hay que tener aguas medicinales”.

Es curioso, ser un balneario es algo que está definido y al parecer requiere de aguas medicionales para poderse llamar así. Sin embargo, una organización entiende que la palabra Balneario le sirve para vender más y no quiere renunciar a ella aunque se salten las normas.

¿Esto no nos recuerda a Scrum?

Scrum está claramente definido en la guía, y, por definición es difícil de dominar. Muchas organizaciones han decidido que quieren tener equipos Scrum ¡Perfecto!. Sin embargo cuando nos cuentan lo que es ya no estamos tan ilusionados:

  • ¿Equipos autoorganizados? Bueno se autoorganizarán pero para entregar en fecha lo que yo diga.
  • ¿Equipos multifuncionales? No vamos a cambiar la estructura de la organización, si necesitan algo de sistemas que hagan una petición.
  • ¿Entrega de valor en cada Sprint? Bueno, mejor lo dejamos para un Sprint final de subida.
  • ¿Contarle al cliente la verdad? ¡No! mejor hagamos un Scrum diferido que nos permita seguir facturando.

Scrum sin cambiar nada no funciona

Saltarte las normas no te ayuda a tomar buenas decisiones

Me parece exactamente el mismo caso que Marina D’or, no puedes saltarte las normas, si no sigues Scrum no puedes decir que lo haces. Aquí la honestidad juega un papel clave. ¿Quieres ser recordado por hacer bien las cosas o por tirar como sea? Debo decir que están teniendo más éxito los segundos, evitan muchas conversaciones difíciles.

Eso sí, posiblemente acaben teniendo un problema grande que tendrán que solucionar horas extra y fines de semana ¿Dónde está la mejora que nos prometía Scrum? ¡Ah! y hay más, puede que después de todo el esfuerzo nadie quiera nuestro software porque no inspeccionamos el mercado hasta el final.

Hace tiempo discutía con un amigo sobre la “piratería” de software. Cuando éramos jóvenes era bastante habitual y un día estuvimos discutiendo sobre ello. Él argumentaba que “para mí eso no es delito porque la cultura no es delito”. Pareciéndome bien su argumentación volvemos al mismo ejemplo, “como para mí beneficio esto debe ser así, diré que es así”. Una vez más, a Marina d’or le interesa decir que es un balneario y a muchas empresas decir que son ágiles.

Transformaciones Agile

Algo parecido está pasando con las Transformaciones Agile. Hablando del método generalista que siguen la mayoría de empresas creo que no es el camino. Venden una relación de tres meses con una facturación inmensa. Después hablan de que todo ha sido un éxito. ¿Hay alguna opción de que no lo sea? La empresa transformadora no le interesa decir lo contrario y la empresa transformada necesita justificar la inversión, es un negocio redondo para ambas, ya podemos ir a eventos a contar lo bien que lo hemos hecho y añadir contenido en nuestras webs para decir que nos hemos transformado. Sin embargo, en esas empresas no hay software en producción en menos de 30 días ¿De verdad te has transformado? Sin entregar software en menos de 30 días no podrás inspeccionar y por tanto no tendrás ningún beneficio de Scrum y no serás ágil.

Orientarnos a producto con Scrum

El problema viene porque solo introducimos las partes de Scrum orientadas al desarrollo de proyectos, olvidando las que realmente nos llevan a un desarrollo de productos. La Review la orientamos hacia una demo para saber el avance del proyecto en vez de analizar el mercado para descubrir si el producto funciona. En la Daily necesitamos que haya reporte para saber si en este Sprint avanzamos respecto al plan maestro y fecha que nos obligaron construir y comprometernos, en vez de ser un ejercicio de inspección respecto al Sprint Goal que acordamos entre todos. Hacemos Sprints de Ux previos y de QA posteriores para optimizar el trabajo de esos perfiles en vez de juntarlos a todos y orientarnos a la entrega en base a la autoorganización. Si nos fijamos, esto ocurre porque solo implantamos los métodos sin entenderlos, las prácticas sencillas que no cuestan en vez de asumir el cambio de mentalidad.

Edulcorar Scrum para no asumir cambios

Y así está el mundo, sinceramente estoy un poco desencantado de todo esto. Edulcorar Scrum para poder venderlo me parece la forma más triste de acabar con una manera diferente de pensar basada en valores y en hacer las cosas bien.

Hace unas semanas impartí una formación a varios mánagers de una empresa. Al comenzar siempre pregunto por sus expectativas respecto al curso y varios pidieron lo siguiente: “queremos saber cómo aplicar Scrum a nuestro proyecto”. Curiosamente una chica me pidió lo siguiente “cuando venga alguien a contarme Scrum quiero saber si me está engañando o no”.

edulcorar Scrum

 

Tras varias horas vieron un Scrum muy diferente al que les habían contando. Scrum no se amoldaba a sus proyectos porque no está pensado para eso. A la compañera que pidió que no la engañarán se lo explique: “No se cómo aplicar Scrum en vuestros equipos, os he traído la verdad, y ahora podemos sentarnos a trabajar para entregar valor”. Esta compañera me miró con cara de “ufff esto es difícil” pero vi que seguro que lo intentaría, he visto esa mirada antes y es la mirada de alguien que encuentra respuestas aunque lo lleven a un camino difícil. Esa mirada es la de la consciencia de una persona que la estaban durmiendo con un Scrum que no resolvía los problemas reales de la organización. Scrum es un camino duro, pero lleva a lugares maravillosos.

Y tú ¿Qué clase de Scrum haces en tu organización?

Deja un comentario