El gran truco para ser ágil e imitar a Spotify

Desde que el año pasado Spotify sacara a relucir cómo es su cultura ágil, cómo se organizan y cómo han conseguido hacer pasos a producción cada poco tiempo (por si no los has leído aquí tienes los post de Spotify Engineering culture 1 & 2) no hay sitio en el que no me encuentre a alguien que quiera ser como Spotify.

Reconozco que me encanta que Spotify haya explicado cómo se organiza (conseguir el cambio en una empresa tan grande y distribuida es una gran inspiración) y que tomo ideas de cómo lo han hecho para aplicar en mi día a día, al igual que también las tomo de otros casos de éxito o de mis propias experiencias. Pero mucha gente en su intento de querer ser ágiles lo que hace es coger esa cultura de Spotify, “llevarla” a su empresa y decir: hay que hacer esto, esto y esto, como Spotify, si a ellos les ha funcionado a nosotros también. Esto no es Scum de libro como venden otros, es real y funciona, ya que una empresa lo lleva a cabo.

Pues bien, aquí tengo varias preguntas para ti:we_are_not_spotify

¿Tu empresa desarrolla una aplicación de música por Internet? 

¿No? Entonces puede que el modelo de Spotify no te funcione.
Pero es que incluso aunque seas una empresa que desarrolla una aplicación de música por Internet, no tiene por qué funcionarte su modelo. Si no, fíjate en el ejemplo de General Motor’s, intentando copiar el proceso de Toyota.

Por lo que seguimos…

¿Tienes a X empleados distribuidos por X países diferentes? ¿Tu empresa tiene contratados clones de los empleados de Spotify con los mismos pensamientos, cultura y especializaciones técnicas?

¿No? Qué lástima. Entonces puede que el modelo de Spotify no te funcione.

¡Piensa que su modelo incluso no siempre le ha funcionado a Spotify! ¡Antes estaban perdidos, como tú, como cualquier empresa! ¡Seguramente tardaron años en llegar hasta allí, y seguro que algunas veces mejoraron de forma accidental, sin darse cuenta, solo que continuaron adaptándolo hasta llegar a donde están!

Además lo más probable es que dentro de unos años ese modelo habrá cambiado, como seguramente cambiarán ellos, y en ese momento cuenten como lo que antes decían que funcionaba, ahora ya no funciona. Eso es lo sano y lo importante en una empresa.

Copiar las ceremonias, los roles y los nombres de una empresa, no copia su cultura.

Y copiar algo sin someter a crítica, imponiéndolo a los empleados, es un mando y control, justo lo contrario que promueve la agilidad.

Por otra parte…¿Por qué si alguien famoso (persona o empresa) promulga algo como bueno, le damos una oportunidad, pero si lo hace una persona normal, de tu empresa, lo rechazamos como bueno? ¿Quién vive el día a día de tu empresa? ¿Spotify o las personas de tu empresa? ¿Quién sabrá mejor los problemas que hay y cómo poder sentirse más a gusto?

Yo entiendo que todos queramos coger un modelo que funcione y aplicarlo tal cual a nuestra empresa, sin complicaciones, fácilmente, pero eso es una utopía.

He querido escribir este post para recalcar esto, que puede ser que tenga esta visión porque en 233 nos dedicamos al mentoring o la consultoría, pero estoy convencida de que tú al pasar por varias empresas te has dado cuenta de que no son iguales, no trabajan igual y lo que funciona en una no tiene por qué funcionar en otra. Por lo que la agilidad, Scrum, no funciona igual en todos los sitios.

Podemos tomar ideas de otras empresas, pero tenemos que integrarlas en nuestro propio modelo y adaptarlas a nuestro contexto, que es lo complicado, pero lo que finalmente merece la pena.

Siempre lo digo, pero he conocido empresas en las que un Scrum casi de libro, con pocas adaptaciones, ha funcionado.

Otras que han adoptado muy bien la cultura de equipo multifuncional porque ya trabajaban así antes, y nunca han concebido otra manera de trabajar distinta a esa. Pero también he vivido y vivo otras empresas en las que hay barreras que les impiden ser multifuncionales y hay que romperlas: los roles han estado separados mucho tiempo, no se llevan bien, no entienden lo que hace cada uno, etc.

Incluso hay empresas que a la hora de implantar Scrum, tienen el problema de que no tienen dinero para contratar a personas específicas para ciertos roles y hay gente que tiene que hacerlo a la vez, mientras que para otras, contratar nuevos empleados especializados no es ningún problema.

Hay empresas que nunca podrán llegar a ser ágiles por ser excesivamente rígidas y procedimentales. Mientras que a otras siguen en el camino de llegar a serlo porque no tienen ningún procedimiento: ni política de control de versiones, procesos de QA, testing, etc. Y esto ni lo dice Scrum, ni lo dice la agilidad, lo dice el sentido común, la Ingeniería del Software. Es algo que hay que tener y que frena el desarrollo software.

Entonces, ¿cuál es el gran truco para ser ágil e imitar a Spotify?

Lo que creo que podemos hacer para realmente ser ágiles e imitar a Spotify, es encontrar qué modelo nos funciona. Modificarlo continuamente, mejorarlo, experimentar y aprender de nuestros errores. Lo que llamamos mejora continua.

Te apuesto lo que quieras a que ese modelo que obtendrás como resultado, se adapta a tu empresa mejor que cualquier otro, incluso mejor que el de Spotify.

Para ello, mi consejo es que primero detectéis los problemas que tengas en tu empresa, planteéis acciones para solucionarlos y vayáis revisando lo que va pasando.

Incluso poneos una meta general, y estableced pasos y responsables para llegar a ello, todo ello dentro aplicando la mejora continua: definir, probar, experimentar, revisar, mejorar.

Incluso identificad posibles cosas que puedan salir mal en las acciones que planteáis, para evitarlas y poner remedio: impedimentos técnicos, personas concretas o temas culturales y tratad de ver por qué hay esos problemas…

¿Es que fulanito no quiere la agilidad porque quiere tener el control de todo y teme que en un equipo multifuncional no pueda ser imprescindible, pisen su trabajo y le echen? ¿Es que él siempre ha querido ocupar un puesto de liderazgo y mejora? ¡Pues que participe en el proceso de mejora!

¿Es que los miembros del equipo no entienden qué es la calidad del software? ¿Hace falta concienciación, formación? ¿Es que hay problemas de visibilidad?

Experimenta, toma ideas de otras empresas, modelos, prueba y mejora. No existe nada que siempre funcione en todos los sitios, ni la agilidad ni otras metodologías anteriores.

Ni siquiera los modelos de procesos como CMMI o la ISO 15504 te dicen cómo tienes que hacer las cosas, sino que plantean las actividades que tienes que hacer para tener un buen proceso software.

¿Cuándo en desarrollo software se nos ha dado una forma de organización o de hacer las cosas que se tenga que tomar al pie de la letra? ¿O siempre han sido consejos y buenas prácticas? Dejemos de quejarnos, y pasemos a la acción. Construyamos nuestros propios modelos y culturas.