Escuche por primera vez sobre escuadrones (squads), tribus (tribes), capítulos (chapters), etc en una charla de Freddy CEO de Platzi, había llegado a Lima a entregar un talk relampago en Laboratoria, fue años antes de qué el término se volviera “sexy“, años antes de que se pudiera medir el éxito del mismo y años antes de que resonara como tambor en multinacionales tradicionales, en ese momento era sólo lo que hacía Spotify y lo que algunas stratups comenzaban a emular, quedé maravillado de saber cómo funcionaban las (no tan) startups tecnológicas desde dentro, era completamente diferente a lo tradicional… lo sentí como una crítica al sistema, un grito de libertad… Salí tan inspirado que comencé a averiguar sobre estos nuevos approaches en internet, pero qué creen? No encontré nada… Para mi muy mala suerte esa info aún no era tan pública, y pues allí estaba yo… decepcionado, disminuido… sin embargo siempre quedó en mi y en mis apuntes, esa interesante “cultura” de ingeniería.

Actualmente el modelo Spotify ha servido de base para el desarrollo de modelos/ways of working desde multinacionales como ING, hasta startups como Laboratoria, quería hablar sobre algunos pensamientos con los que me he topado en el día a día, que pienso son importantes tener en cuenta al momento de hablar del Modelo Spotify o del diseño de modelos de trabajo Agil, pues la implementación en compañías grandes es diferente que en Startups, sobretodo porque existe un componente de governanza, procesos, cultura, change management y liderazgo desde la dirección, entre otros, necesario para poder transformar “las formas de trabajar” y esto por supuesto es una tarea bastante compleja.

Una estructura que responde a Agilidad

Una estructura de trabajo que responda a la Agilidad, es una estructura que tiene la suficiente autonomía para poder responder y ser flexibles a los cambios, ser flexible podría devenir en ser más “rápidos” (entregar más rápido, innovar más rápido, etc), pero el concepto Agil (Agile) no solamente se enfoca en ser rápido, este es un primer error de concepto que he podido escuchar y es importante porque los equipos responden al objetivo de su formación, para tener un buen modelo necesitamos que la compañia entienda lo mismo por Agilidad en todos sus niveles, la estructura sólo es una pieza del rompecabezas, Spotify creo el modelo según lo que necesitaba en ese momentum, a través de algunos talleres los Agile Coach idearon el concepto y una extensión del manifiesto Ágil (Agile a la Spotify) que se imprimió en todas las paredes de sus oficinas al mismo tiempo que mejoraban sus estructuras pero enfocadas en desarrollo e ingeniería, definir claramente que es ser Agil para tu compañía es muy importante pues tú no eres Spotify y no necesitas lo que Spotify en el 2013.

Entendiendo esto, los equipos necesitan tener algunas caracteristicas, como:

No hay texto alternativo para esta imagen
Estructuras de trabajo Agile

Las estructuras de trabajo para responder a Agile/Transformation necesitan estar estar conformadas por grupos independientes, autónomos, multidisciplinarias, y que posean control end-to-end de sus iniciativas, esto elimina la burocracia en los procesos y brinda facilidad a la estructura de la organización para adaptarse rápidamente a los cambios que se requieren. Es aquí donde los Squats y Tribus cobran vida, estos equipos deben estar conformados por “Business & Tech people” y deben responden a un objetivo, meta o misión relacionada con el negocio, reduciendo conceptualmente así los silos, pero no funcionan si no existen modelos tropicalizados a la realidad de la empresa y con un marco de gobierno común.

En Spotify la falta de planificación y estandarización centralizada permitió la hipervelocidad, el hipercrecimiento y la hiperinnovación, pero hizo mucho más difíciles ciertas cosas que son fáciles para organizaciones más tradicionales, esto se entendió años después cuando ya no eran una startup sino una multinacional, cambiar todo tu modelo para hacerlo “Spotify” te puede traer más problemas de los que ya tienes.

No hay texto alternativo para esta imagen
Ejemplo de estructura Agil basada en Squats para CPGs

Squads, Tribes, Chapters suena a algo diferente

Pero si hablamos de roles son casi Scrum Teams, el problema con Scrum es que es muy bueno para la gestión de un sólo equipo (no me maten por esto), pero cuando diferentes equipos deben comunicarse entre ellos y coexistir organizados (hablamos de equipos de al más de 70 desarrolladores) las cosas cambian un poco, es allí donde Spotify crea una cultura para abordar el crecimiento a un equipo de ingeniería de 10 a 300 personas, si entendemos el concepto detrás de ello podemos comprender la base del modelo y buscar tropicalizarlo, más no copiarlo, es allí donde se define una Metodología de proyectos, un Modelo operacional y un sistema de gobierno, además de crear realmente una cultura en la agilidad, que entre otras cosas, conforman los Ways of working. Sea en multinacionales o startups, la escencia podría ser similar de menor a mayor nivel.

Otro error de concepto es creer que estos roles son creados por Spotify, cuando han existido antes en muchos enfoques Agiles/Lean, el reto es entender la finalidad de estos y crear un modelo personalizado a la naturaleza de nuestra organización. Estos ways of working siempre tienen un componente relacionado a PPM, y PPM tiene una capa fuerte en governanza, olvidarnos de esto para entregar sobre-autonomía podría traernos problemas que no existen ahora, el reto siempre estará en el fit de ambos.

¿Qué es lo mejor de trabajar en Spotify? ¿Qué es lo más difícil de trabajar en Spotify? La respuesta para ambas preguntas es la misma: Autonomía – Joakim Sundén

Hay muchos pensamientso (no necesariamente correctos) que tengo sobre este tema y quisiera abordarlos luego, pero entonces, ¿Qué podemos hacer si queremos ganar agilidad, velocidad e innovación? ¿Por dónde empezamos?

Primero, toca preguntar, ¿Tenemos claro qué problemas soluciona nuestro modelo? Y si es posible, qué indicadores medibles tenemos de lo que debe mejorarse.

Debemos involucrar no solo a los equipos de la alta dirección, sino a la organización completa para recopilar ideas y crear conjuntamente la imagen de dónde queremos nuestro modelo. No sólo necesitamos ser ágiles, nos toca preguntarle a las personas ¿De qué forma hacemos que la manera en la trabajamos sea mejor?

Recordar que no debemos cambiar todo para ser como otras compañias, debemos conservar lo que hacemos bien y lo que nos hace únicos, para así decidir que rescataremoss para nuestro nuevo modelo, pues es nuestra escencia.

Tenemos que inspirarnos en una amplia variedad de prácticas y empresas. Observar diferentes modelos que se ajusten a diferentes contextos de escala y riesgo. Ver más allá de Spotify e incluso más allá de Agile!

Diseñear e iniciar una serie de programas piloto que nos ayuden a probar nuevos ways of working, approach, filosofías, modelos… que nos permitan aprender rápidamente si se ajustan a nuestra realidad. Ampliar los pilotos que se muestran prometedores y acabar con los que no producen el efecto que estamos buscando.

Ha pasado algo de tiempo, pero sigo viendo el modelo Spotify como en aquella charla de Freddy, con mucha admiración e inspiración, pero ahora me cuestion un poquito más sobre los modelos operaciones y de proyectos Agiles, los veo como un musculo en constante ejercicio y cambio, complejos por supuesto pues siempre él éxito de estos dependerá de las personas que los usen en el día a día y no de los que estamos diseñandolos…

Por último, no hagamos un modelo Spotify, inspiremonos en él y creemos nuestros propios modelos/ways of working…

(Continúa)

Julio Toribio

Author Julio Toribio

Transformation Yedi Diseñador Traveler

More posts by Julio Toribio

Leave a Reply