Scrum en equipos muy grandes. ¿Qué hacemos?
Laura Atehortua Giraldo
¿Qué haces cuando una camiseta te queda pequeña?
¿La botas? ¿La regalas? ¿Dices que ya no sirve o qué es mala?
En el mundo empresarial, más específicamente hablando en la adopción de agilidad existen marcos y prácticas de diferentes tamaños. Muchas de estas juzgadas por no servir, desechadas o simplemente consideradas para lo que realmente son.
Siempre he recomendado a la hora de decidir prácticas ágiles, no tomar a ciegas lo que el mercado dice, sino considerar cuál es la forma y estructura de tu organización para saber cuáles pueden servir mejor.
Para ejemplificarlo mejor, Scrum es un marco que viene en diferentes tallajes. El que más conocemos es como su referencia pequeña, el cuál a lo largo de las últimas 2 décadas ha sido muy adoptado por organizaciones en el especial en el desarrollo de productos digitales para mejorar la agilidad de los equipos que están integrados entre 3 a 9 personas.
Incluso, en la conformación de equipos Scrum, empecé a usar las palabras de Jeff Bezzos que me parecieron muy interesantes:
“Sino eres capaz de alimentar a un equipo con 2 pizzas, es porque es demasiado grande”
Y si que me gusta, porque en Colombia por ejemplo, minimo una persona se come 2 porciones jejejeje.
Pero, en los retos organizacionales y en especial con la escalabilidad de la transformación digital dentro de las empresas, se comenzaron a ver equipos de desarrollo cada vez más grandes, plataformas más robustas y retos que implicaban muchas más personas en pro de una misión.
Vi muchos equipos trabajando Scrum con hasta 20 personas e improvisando para no perder las bondades del marco que venía dándoles muy buenos resultados.
Pero en esos momentos donde un marco Scrum base se siente como una camiseta pequeña en un cuerpo mucho más grande.
¿Está mal Scrum?
No, simplemente es momento de abrirle las puertas a sus diferentes formas de escalamiento y es donde nos encontramos que esta situación también la han vivido otras personas e incluso sus creadores, lo cual hizo que se derivaran algunos marcos de escalamiento como Nexus, sAFE, LeSs y Scrum Scale (creado por Jeff Sutherland).
Al igual que el marco base, Scrum Scale contiene una guía, se basa en sus prácticas base y nos muestra cómo podemos escalarlo a estructuras mucho más grandes. Así, como nos hace énfasis en la importancia de las prácticas ágiles que debe adoptar cada equipo dependiendo del tipo de producto que está construyendo, para sacar el máximo provecho, pues este no es una metodología, sino una forma de organizarse para tener resultados incrementales y evolutivos bajo la mentalidad del empirismo.
En WorkChangers hemos vivido experiencias muy gratas con Scrum Scale y otras no tanto. Cuando escalamos asumimos una responsabilidad mayor y se pone a prueba si las bases realmente están solidas o débiles para ir al otro nivel.
Una empresa puede necesitar escalamiento en Scrum por el tamaño de sus retos, pero derribarse por falta de bases en temas clave del Scrum no escalado.
Por eso es muy importante como agilistas, conocer bien sus bases, saber diagnosticar de forma transparente si nos dan la solidez para escalar y cuáles son los riesgos que podríamos afrontar a la hora de hacerlo, para hacer un buen equipo de gestión del cambio y crear un buen marco de referencia de escalamiento en nuestra organización.
¿Te gustaría saber más de esto último que dije?
Déjanos saberlo en los comentarios de este blog para compartir contigo una serie de artículos de este tema tan interesante del cual también ya puedes encontrar certificación en el portafolio de Certiprof.
Daniel Moncada
CEO Workchangers
¿La botas? ¿La regalas? ¿Dices que ya no sirve o qué es mala?
En el mundo empresarial, más específicamente hablando en la adopción de agilidad existen marcos y prácticas de diferentes tamaños. Muchas de estas juzgadas por no servir, desechadas o simplemente consideradas para lo que realmente son.
Siempre he recomendado a la hora de decidir prácticas ágiles, no tomar a ciegas lo que el mercado dice, sino considerar cuál es la forma y estructura de tu organización para saber cuáles pueden servir mejor.
Para ejemplificarlo mejor, Scrum es un marco que viene en diferentes tallajes. El que más conocemos es como su referencia pequeña, el cuál a lo largo de las últimas 2 décadas ha sido muy adoptado por organizaciones en el especial en el desarrollo de productos digitales para mejorar la agilidad de los equipos que están integrados entre 3 a 9 personas.
Incluso, en la conformación de equipos Scrum, empecé a usar las palabras de Jeff Bezzos que me parecieron muy interesantes:
“Sino eres capaz de alimentar a un equipo con 2 pizzas, es porque es demasiado grande”
Y si que me gusta, porque en Colombia por ejemplo, minimo una persona se come 2 porciones jejejeje.
Pero, en los retos organizacionales y en especial con la escalabilidad de la transformación digital dentro de las empresas, se comenzaron a ver equipos de desarrollo cada vez más grandes, plataformas más robustas y retos que implicaban muchas más personas en pro de una misión.
Vi muchos equipos trabajando Scrum con hasta 20 personas e improvisando para no perder las bondades del marco que venía dándoles muy buenos resultados.
Pero en esos momentos donde un marco Scrum base se siente como una camiseta pequeña en un cuerpo mucho más grande.
¿Está mal Scrum?
No, simplemente es momento de abrirle las puertas a sus diferentes formas de escalamiento y es donde nos encontramos que esta situación también la han vivido otras personas e incluso sus creadores, lo cual hizo que se derivaran algunos marcos de escalamiento como Nexus, sAFE, LeSs y Scrum Scale (creado por Jeff Sutherland).
Al igual que el marco base, Scrum Scale contiene una guía, se basa en sus prácticas base y nos muestra cómo podemos escalarlo a estructuras mucho más grandes. Así, como nos hace énfasis en la importancia de las prácticas ágiles que debe adoptar cada equipo dependiendo del tipo de producto que está construyendo, para sacar el máximo provecho, pues este no es una metodología, sino una forma de organizarse para tener resultados incrementales y evolutivos bajo la mentalidad del empirismo.
En WorkChangers hemos vivido experiencias muy gratas con Scrum Scale y otras no tanto. Cuando escalamos asumimos una responsabilidad mayor y se pone a prueba si las bases realmente están solidas o débiles para ir al otro nivel.
Una empresa puede necesitar escalamiento en Scrum por el tamaño de sus retos, pero derribarse por falta de bases en temas clave del Scrum no escalado.
Por eso es muy importante como agilistas, conocer bien sus bases, saber diagnosticar de forma transparente si nos dan la solidez para escalar y cuáles son los riesgos que podríamos afrontar a la hora de hacerlo, para hacer un buen equipo de gestión del cambio y crear un buen marco de referencia de escalamiento en nuestra organización.
¿Te gustaría saber más de esto último que dije?
Déjanos saberlo en los comentarios de este blog para compartir contigo una serie de artículos de este tema tan interesante del cual también ya puedes encontrar certificación en el portafolio de Certiprof.
Daniel Moncada
CEO Workchangers
