¿Diferentes estrategias para escalar Scrum en las empresas?

Casi una de las primeras preguntas cuando nos metemos en el mundo de Scrum es, si se basa en equipos pequeños, ¿cómo hago para implantarlo en mi empresa, si somos 50 desarrolladores? ¿y en una empresa mucho más grande? ¿cómo coordinamos los equipos? ¿cómo evitamos dependencias entre ellos?

Si tus equipos individuales son muy buenos técnicamente, pero la comunicación entre ellos es mala, la cosa no funcionará. Y viceversa, si la comunicación entre equipos es buena, pero hay problemas en algún equipo individual, pasará lo mismo.

Ante esto, a lo largo del tiempo distintas empresas y autores han planteado diferentes soluciones. En muchos de los casos, esas soluciones se han documentado en forma de casos de estudio o incluso “métodos” certificados para escalar Scrum.

En mi opinión, esas soluciones no pueden verse como algo “que siempre funciona”, es decir, como poder coger una serie de pasos y utilizar dichos pasos para escalar Scrum correctamente en cualquier empresa.

Por ejemplo, y con todo mi respeto, cuando alguien me dice que está certificado para implantar SAFe, y que siempre vende eso en todas las empresas, sin mirar la situación de dicha empresa antes, me echo a temblar (pero esto es algo personal).

Mi sensación es que la situación de cada empresa a la hora de escalar la agilidad es diferente, y sus problemas clave también lo son. Por lo tanto la solución en cada caso puede llegar a ser diferente.

Si que es cierto, que se repiten patrones, o cosas que han funcionado en ciertos sitios, y puede que podamos tomarlas y adaptarlas a nuestra situación. O mezclar ideas de un sitio y de otro.

Por eso me gusta ver todas estas estrategias como sitios de donde tomar ideas que luego habrá que adaptar a las distintas empresas.

A continuación voy a resumirte las principales estrategias que se han ido proponiendo a lo largo del tiempo a la hora de escalar Scrum. Pero tómalas como estrategias, sitios de donde coger ideas.

Para mí, escalar Scrum con éxito parte de la idea de que toda la organización (incluido managers, gente de negocio) entienda y promueva los principios ágiles y Scrum (Roles, responsabilidades, fomentar la creatividad y el buen trabajo en equipo, la calidad técnica, etc).

Por ejemplo, un manager que diga “sí, queremos calidad de código, o mejorar este proceso, pero ahora no tenemos tiempo, olvídate de la calidad, saca las cosas de cualquier manera”…Se puede cargar todo esto. O somos constantes y vamos dando pequeños pasos realistas hacia lo que queremos conseguir, o seguiremos igual.

Y por otra parte, piensa que si alguien tuviera una solución única para escalar Scrum que siempre funcionara, no existirían tantas propuestas.

SAFe: Scaled Agile Framework, de Dean Leffingwell.

Aquí te dejo un post sobre en qué consiste SAFe. Tienes un programa de certificación, un roadmap para implementarlo, empresas que lo apoyan y que hacen implantaciones.

LeSS. Large Scale Scrum, de Craig Larman y Bas Vodde.

Aquí tienes un post sobre LeSS, y más información en su página web. El caso de Spotify, se parece más a lo que propone LeSS.

DAD. Disciplined Agile Delivery, de Scott Ambler.

La semana que viene escribiré un post sobre este enfoque, ya que tiene similitudes y diferencias con respecto a SAFe y LesSS.

Es un framework que se centra en todo el proceso de desarrollo software, desde la toma de requisitos hasta la entrega en el cliente, y para ello combina ideas de Scrum, Lean, XP, Kaban, etc.

Como novedad, DAD tiene en cuenta la gestión de cualquier cambio, ya sea de hardware a la hora de hacer un despliegue, mejoras de procesos, etc.

Está centrado en metas, y para conseguirlas te van dando consejos que pueden ser útiles o no en tu empresa, de cara a la implantación de DAD.

Fue desarrollado originalmente por IBM (aunque no es necesario ninguna herramienta para implantarlo, ni hay que depender de ellos), y también tiene un programa de certificación.

Scrum Plop (Patrones de Scrum).

Existe una comunidad que elabora patrones de Scrum. Entre los miembros más destacados de este grupo, se encuentran Jeff Sutherland (inventor de Scrum) y Jim Coplien.

Hay ciertos patrones relacionados con escalar Scrum, por ejemplo el de tener un Chief Product Owner responsable de maximizar el Retorno de Inversión de un Product Backlog Global, y un grupo de Product Owners a su cargo que le aconsejan y le ayudan a gestionar dicho backlogs más pequeños, o Scrum de Scrums, para coordinar varios equipos Scrum.

Terminando…

Cuando navegas un poco entre las distintas estrategias, te das cuenta de que además de los principios ágiles, muchas de esas estrategias comparten elementos entre sí, como por ejemplo la idea del Scrum de Scrums.

Muchas las estrategias han ido surgiendo como mejoras de carencias encontradas en las anteriores (por ejemplo, los creadores de DAD dicen que es algo complementario a SAFe o LeSS, que suple sus carencias).

Yo no me voy a meter en decir cuál es la mejor estrategia de todas, ya que como he dicho, me gusta ver este tipo de cosas como consejos, pautas sobre las que tomar ideas que serán adaptadas de acuerdo a la situación de la empresa.

Por último, me gustaría que te quitaras de la cabeza la idea de: si mi empresa es grande, no puedo implantar Scrum. No te centres solo en el número de personas para decidir si es viable implantar Scrum o no. Y lo mismo para un equipo pequeño. Céntrate más en las características de tu negocio, desarrollo y prácticas de tu empresa además de en el número de personas.

No pienses que si estás una empresa grande, ya no necesitas Scrum y con SAFe, DAD (inserta aquí el framework que más te guste) es suficiente. Todos estos frameworks no son sustitutos de Scrum. Son propuestas para escalar Scrum, y en muchas de ellas, necesitas interiorizar la mentalidad ágil para poder aplicarlas con éxito.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba