Scrum

¿Cambiar Scrum? ¡Espera!

Existe un eterno debate desde que Agile llegó a las empresas: ¿debemos adaptar los métodos a la empresa? La estrategia más sencilla es hacerlo, todo modelo, método o práctica que llega de fuera siempre será visto como “teórico”, al final, la persona que lo ideó está a cientos de kilómetros de nuestra organización, no conoce nuestra realidad ¿O tal vez sí? 

El sentido común nos impide avanzar

Cuando trabajamos un cambio, siempre tenemos dudas, nos genera ansiedad. Un cambio consiste en aceptar que, hasta ahora, no hacíamos bien las cosas, podemos mejorar. A todos nos ha costado incluir Agile en nuestra manera de trabajar y de pensar, la planificación es demasiado tentadora. 

Uno de los grandes argumentos que usamos para no cambiar es el manido “sentido común”. Algunas frases típicas que podemos escuchar: 

  • Es de sentido común darle precio al cliente, tiene que saber lo que costará
  • Estimar todas las tareas es de sentido común, así podemos hacernos una idea de lo que llevará 
  • Si el cliente no quiere participar de Scrum, pues que no lo haga, es de sentido común

El sentido común se aferra a nuestro instinto de supervivencia, si enfado a un cliente al no darle precio o estimar tareas, puedo perderlo, eso es clave. Si evito darle una planificación detallada a mi jefe, se generará tensión entre ambos, ¡no me interesa llevarme mal con mi jefe! 

El sentido común existe para protegernos. El sentido común nos decía que no abandonáramos la cueva en la prehistoria, allí  estábamos calentitos. En la época franquista española, era de sentido común acudir a misa los fines de semana para evitar que hablaran mal de ti, es más, de que sospecharan que eras del bando perdedor y te generara un problema. El sentido común genera una barrera que nos protege pero, también, nos impide avanzar. 

El cambio y el sentido común suelen ser incompatibles, empecemos a trabajar el cambio pensando diferente o el sentido común acabará por lograr que nos estrellemos. 

Respeto y coraje

Que Scrum tenga entre sus valores el Respeto y el Coraje es clave para afrontar la dificultad de implantar Scrum. De hecho, utilizar Scrum no debe ser el objetivo, sino el medio para maximizar la entrega de valor por parte de los equipos y de la organización. 

Sin embargo, es más sencillo “adaptar Scrum”, es más fácil renunciar a algo difícil que requiere un cambio estructural fuerte en la organización. De hecho, muchos “Scrum Master” lo hacen, les va mejor, es más sencillo usar el sentido común que hacer ver a tu empresa que estáis perdiendo mucho dinero haciendo un software que aporta poco o nada de valor. 

El valor Respeto, además, va mucho más allá de que un equipo se trate bien. El valor Respeto se refiere a respetar el propio marco Scrum, a las personas que lo crearon y a las personas que trabajan cada día para que sus equipos sean adaptativos. 

“Has hecho lo que esperaba de ti”

Hace años trabajaba para una organización en su Transformación Agile. Un verano, tuvimos un debate interno sobre cómo medir la productividad individual, lo que nos llevó meses sobre lo contraproducente que podría ser para equipos ágiles. En vez de facilitar esta métrica, pasé semanas argumentando los perjuicios de medir individualmente a los miembros de un equipo a los que se les exigía como equipo, sobre todo si usaban Agile como filosofía de trabajo. 

Meses después, tocó marcharse de la empresa y aproveché la ocasión para preguntarle a mi responsable: “¿Hice bien en aquel debate?”. Desde mi punto de vista, podía quedar como un aliado de la empresa si hubiera claudicado, sin embargo, como agilista, debía poner en duda la utilidad de esta métrica. 

Su respuesta fue: “hiciste lo que esperaba que hicieras”. Ahí aprendí varias cosas, por un lado, que la carrera de un agilista es durísima, porque vas a tener que poner en duda la estructura, las reglas, la cultura de la organización, siempre que afecte a los equipos y a su capacidad de entrega. También aprendí que, muchas veces, sobrevivir en las empresas iba a ser una tarea complicada. 

Cambiar Scrum para tapar los problemas

Scrum propone un cambio muy disruptivo. Casi todas las empresas que me he encontrado lo han visto muy anti-natural, por lo que distaba el marco con respecto a su manera de trabajar. Sin embargo, tiene una ventaja clara, como comentan Ken y Jeff. Scrum levanta todas las deficiencias organizativas que nos impiden entregar valor, veamos algunos ejemplos: 

  • Muchos departamentos que no colaboran.
  • Métricas orientadas al rendimiento y no al resultado.
  • Mala comunicación entre los developers y los usuarios finales.
  • Sistema de bonus que premia actitudes negativas.
  • Foco individual sobre el trabajo del equipo.

Todas estas deficiencias son contrarias al desarrollo software y, por tanto, a ser capaces de producir productos digitales que entreguen gran valor. Scrum nos ayuda a detectarlas, pero no a resolverlas, eso es trabajo de la propia organización y de las personas que lo componen. 

Cambiar o morir

En un mundo tan cambiante como en el que vivimos, sobre todo en el mundo digital, tenemos que ser muy adaptativos a nuestra realidad. Las empresas no pueden seguir bebiendo de técnicas inventadas hace 100 años cuando el mundo no era tan global, ni tan rápido. El foco en resultados es más importante que nunca y la burocracia de control nos genera más pérdidas de tiempo que beneficio. 

Hay demasiados ejemplos de empresas a las que les está costando acertar con su estrategia digital. Algunas, como Renfe o como muchos bancos, aún funcionan bien porque sus usuarios no tienen elección digital. Que tu usuario use tus productos digitales, porque están obligados, no es sinónimo de éxito. 

Y tú, ¿cambias Scrum o afrontas el cambio? 

5 comentarios sobre “¿Cambiar Scrum? ¡Espera!”

  1. Entiendo que se refiere a cambios sobre el marco scrum. A otros aspectos no porque “El marco de trabajo Scrum es incompleto de manera intencional, solo define las partes necesarias para implementar la teoría de Scrum.”

    Por otra parte si los equipos scrum son autogestionados, ¿no pueden escoger llevar a cabo su trabajo de una forma que no sea scrum?

Deja un comentario