Con el propósito de hacerle frente a los nuevos retos digitales que surgen constantemente, muchas empresas han apostado por una metodología de trabajo Agile que les permita digitalizarse eficientemente. Y es durante este proceso que nacen las tribus y squads. Pero, ¿acaso estas son necesarias para lograr la revolución digital de las organizaciones?
Una de las compañías más conocidas a nivel mundial y que eligió una metodología de trabajo Agile es Spotify. A través de esta desarrolló su producto y en ese proceso nacieron las tribus y squads de la empresa. Este artículo explora más sobre la experiencia de la organización sueca al usar este modelo y los aprendizajes que dejó para el resto de compañías.
Primero, cabe destacar que para Spotify esta metodología Agile era un buen “fit” debido a que se alineaba con los principios organizacionales. Esto nos puede generar la pregunta sobre si estas reglas (y por ende modelo de trabajo) se puede aplicar exitosamente para otras empresas, sin importar si tienen los mismos principios que la compañía sueca.
La respuesta es que las prácticas exitosas de una organización no siempre generan los mismos resultados para otras empresas. Incluso, la tendencia de crear tribus y squads ha generado que como consecuencia estos modelos se repliquen en otras empresas donde debido a circunstancias internas y externas no se logra el objetivo deseado.
Retomando el modelo de Spotify, este se creó desde cero pensando en quiénes eran como compañía y en lo que necesitaban. Cuando lo desarrollaron, se basaron en las dinámicas que les funcionaron en el pasado respecto a la organización de equipos para trabajar en su producto. Uno de los elementos clave de este modelo Agile es su “flexibilidad” en relación a las reglas de trabajo, ya que existe la idea de que se pueden modificar las normas conforme avanza el juego.
En un inicio se cuenta con reglas definidas pero se tiene la confianza de que estas se pueden romper para crear una nueva versión de estas que se ajuste a las necesidades del equipo y negocio.
Dentro de su modelo de trabajo los roles no se encuentran definidos (a diferencia del sistema Scrum). En cambio, Spotify ha hecho sus propias adaptaciones y el Scrum Master es conocido como Agile Coach, mientras que los Scrum Teams reciben el nombre de Squads.
Los Squads también pueden ser conocidos como Equipos o Escuadrones y son completamente independientes entre ellos. Al no tener que seguir reglas o estándares a nivel organización, los Squads tienen la libertad de utilizar las herramientas, metodologías y tecnologías que sean más convenientes para ellos.
Pero, a pesar de esta libertad, los Squads deben de tener elementos en común como los objetivos que buscan cumplir, la estrategia de producto y más; estos con la finalidad de poder trabajar hacia un mismo propósito sin perderse en el camino.
Definitivamente el modelo de trabajo de Spotify puede generar escepticismo. Existen múltiples comentarios de ex colaboradores que han criticado este modelo de trabajo. Incluso, dichas opiniones evalúan a la empresa sueca como un lugar de trabajo que no se caracteriza por ser “Agile”.
“Me preocupa cuando la gente mira lo que hacemos y piensa que es un marco que pueden copiar e implementar. … Realmente nos estamos esforzando ahora por enfatizar que también tenemos problemas. No todo es ‘brillante y todo funciona bien y todos nuestros equipos son súper increíbles».
Anders Ivarsson, co-autor del whitepaper de Spotify.
Fuente: Scaling Agile @ Spotify
Es quien se encarga de coordinar los esfuerzos de los squads involucrados para resolver el problema que se busca atacar. Esta persona es la encargada de comunicar con los “equipos” el porqué es tan importante brindarle una solución a dicho problema con el propósito de asegurarse de que el resto de los squads trabajen por ello y/o brinden ideas que puedan apoyar en la solución.
A un grupo de Squads se le llama Tribu. Su propósito es que los miembros de esta se encuentren todos enfocados hacia el mismo producto. Esta agrupación también tiene como propósito dirigir los esfuerzos del equipo hacia cierto producto o desarrollo. Un ejemplo de ello podría ser la tribu de una aplicación móvil de un banco.
Las tribus pueden estar formadas por 50-150 personas, pero lo ideal es que no supere los 100 colaboradores. Esto solo es un mecanismo de escala que permite que un mayor número de personas trabaje en una función grande.
Estos grupos pueden tener más de un solo líder debido a que dentro de ellos hay diferentes roles con funciones específicas (diseño, ingeniería, producto, negocios, etc.) por lo que se necesita un liderazgo que sea capaz de apoyar al equipo cuando este se encuentre con problemas técnicos.
Son los equivalentes a un Scrum Team y simplemente consisten en equipos multifuncionales que constan de alrededor de 6 a 12 personas. Cada Squad está formado por diseñadores, desarrolladores y analistas de negocio, es decir, todos los roles necesarios para trabajar de principio a fin en un proyecto específico, sin tener que depender de otro equipo para el éxito.
En resumen, los Squads tienen la autonomía necesaria para decidir cómo solucionar el reto al que se enfrenta. Pero nunca perdiendo de vista el objetivo de la organización.
Los capítulos (también llamados chapters, división o departamento) se crearon para reunir a todos los especialistas funcionales de diferentes equipos (diseño, QA, UX, etc.) en una comunidad. Esto les permite discutir sobre su área de especialización y sus desafíos específicos. El líder del capítulo actúa como gerente de línea para todos los miembros del capítulo.
Los gremios son muy similares a los capítulos que se organizan alrededor de una especialidad, como ingeniería o arquitectura. La diferencia es que un capítulo está abierto a cualquiera que tenga interés en el tema. Este es casi el mismo concepto que las “comunidades de práctica” en Agile, solo que con un nombre diferente.
Es posible que una persona pertenezca a uno o varios gremios diferentes. Y también cada uno tiene libertad de decidir su nivel de participación dentro de los diferentes gremios a los que pertenece.
Originalmente, estos grupos nacieron con la idea de practicar habilidades o adquirir conocimientos pero evolucionaron y se llegó a un punto en el que no necesariamente estaban relacionados con el producto en desarrollo o el negocio.
Este modelo llegó a sentar un precedente respecto a cómo se debía de trabajar para lograr resultados de forma rápida y “ágil”. Gracias a la organización autónoma de los equipos, era más fácil hacer frente a las solicitudes que se tenían para solucionar problemas.
Se considera que estos son los principales beneficios del modelo de Spotify:
Al enfocarse enteramente en el trabajo (y en conseguir resultados), el modelo deja a un lado los procesos y las formalidades. No solo eso, sino que también le da flexibilidad a los Squads de elegir la dinámica de trabajo que más se adapte a ellos.
La principal ventaja de no contar con un proceso a seguir es que los equipos pasan menos tiempo respondiendo a las formas de este y más desarrollando el producto o funcionalidad.
El modelo de Spotify brinda la suficiente libertad para que los colaboradores y Squads elijan el mejor método de trabajo y organización para ellos. Con esto, se busca la descentralización de decisiones para que estas sean tomadas por aquellos a quienes les conciernen.
Al darle esta libertad a los Squads, se fomenta un ambiente de transparencia que permite la experimentación como un medio para encontrar nuevas soluciones a los mismos problemas.
Esencialmente, el modelo de Spotify era equivalente a un reetiquetado de una estructura matricial. Cada “Capítulo” era en realidad solo un área funcional (por ejemplo, pruebas, programación, diseño, etc.) que contaba con su propio administrador de personas.
Cada “Tribu” englobababa a un departamento. Mientras que un “Squad” simplemente trata de un equipo multifuncional. Ya que no hubo cambios dentro de estas estructuras, podría asumirse que los nuevos nombres crearon confusión y a su vez, generaron el mito de un cambio significativo.
Partiendo de la línea de la autonomía, Spotify le dio a cada equipo el control sobre sus propios procesos y prácticas. Pero no tenían suficientes coachs para ayudar a todos los equipos y muchos de estos tampoco tenían el suficiente conocimiento de los principios y prácticas ágiles para implementarlos de manera efectiva.
Cuando Spotify lanzó su whitepaper buscaban crear una visión para el futuro, motivados un poco por ambición de sentar precedentes y porque necesitaban una guía a la cual acudir en el momento en el que dudaran de sus próximos pasos. El ex Agile Coach de Spotify, Joakim Sundén habló sobre esto:
“Incluso en el momento en el que escribimos el whitepaper del modelo, no lo estábamos practicando. Fue en parte ambición, en parte aproximación. A la gente le ha costado mucho copiar algo que en realidad no existía.”
Conforme crecía el tamaño de los equipos, la empresa no estandarizó un proceso que facilitara la colaboración entre equipos. Debido a esto, se llegó a un punto en el que cada equipo tenía una forma única de trabajar y no había una base para las opciones. La falta de un estándar generó problemas en la productividad de la organización.
Igualmente, mientras crecía el número de equipos se reconoció que se necesitaba apoyo 100% enfocado en guiar y estructurar la colaboración entre equipos. Por ello, era necesario implementar estructuras especiales con las que se lograra la colaboración entre los Squads que no estaban relacionados.
Para concluir, se pueden retomar las palabras de Henrik Kniberg, creador del modelo de Spotify, quien resalta que a pesar de que esta dinámica parezca un éxito en términos de Agile, donde todo funciona completamente; las realidad es otra.
El modelo de Spotify se creó hace más de 10 años por lo que es poco probable que los problemas mencionados anteriormente sigan existiendo dentro de la organización. Seguramente, la compañía ha mejorado y corregido las fallas; pero aún hay análisis y aprendizaje que se puede obtener de él.
El verdadero aprendizaje se encontraba en la cultura de ingeniería y desarrollo de productos, la cual se diseñó para equipos ágiles, rápidos, motivados y autónomos.
Mientras el modelo estaba vigente, se desarrollaron algunos principios de trabajo básicos que apoyaron su ejecución:
Dentro del modelo de Spotify también existen conceptos que son útiles y para cualquier equipo que busque trabajar de una forma más “Agile” y estos pueden replicarse dentro de las empresas y adaptarse a sus necesidades.
Aplicar un modelo Agile dentro de la empresa no es suficiente para que esta sea innovadora y tampoco bastará para conseguir resultados positivos. Para esto también se necesita que los equipos cuenten con la mentalidad correcta y las herramientas digitales apropiadas para el desarrollo de las soluciones.
Hay que recordar que el objetivo final de toda organización es lograr Business Outcomes. Y si las empresas valoran más ser Agile, se obtendrá la eficiencia como resultado sin llegar al verdadero objetivo.
Para aprender más sobre el tema, lee el Whitepaper “Agile is Not Enough”.
Descubre nuestras soluciones y cómo podemos ayudar a tu empresa alcanzar sus objetivos de transformación digital.
.webp)