Lo de llevar Scrum a empresas grandes es un tema cada vez más y más comentado. Y cuando hablo de “empresas grandes” me refiero a aquellas en las que por el número de personas que hay… no puede haber un solo equipo de no más de 10 personas… y entonces debe haber varios…. lo que conlleva coordinaciones, intentar evitar dependencias, etc.
Recuerda que en Scrum se sigue la premisa de que los equipos grandes en número (más de 9 personas) son menos productivos que los pequeños (lee, o relee, aquel post de que los equipos con mucha gente (más de 7) son menos productivos)
Por ello, los equipos en Scrum son de entre 5 y 9 personas. Y el reto, obviamente, está (y estamos en ello todos los que estamos metidos en proyectos de Scrum en empresas grandes) en implantar Scrum en empresas con más personas, reto que pasa, lógicamente, por organizar tantos equipos de hasta 10 personas como sea imprescindible y lograr la coordinación de los mismos y evitar las dependencias (es decir, con multifuncionalidad)… y sin volver a caer en la burocracia, el sobre proceso, etc.
Hace unos meses ya toque este tema en un par de post, aquella serie de Implantando la agilidad en empresas grandes, donde te contaba cinco decisiones, y buenas prácticas, que que te tocará lidiar a la hora de implantar la agilidad en empresas grandes, no está demás recordarlas: 1 – Scrum Master de los Scrum Master y el Product Owner de los Product Owner, 2 – Reuniones Scrum de Scrums, 3 – Sincronización de los Sprint y de las reuniones diarias, 4 – Equipos especializados frente a multifuncionales y 5 – Una pila de producto para todos los equipos o una pila de producto para cada equipo.
En este nuevo post sobre el tema quiero actualizarte con las iniciativas que más fuerza están tomando, algunas no faltas de polémica, sobre cómo llevar Scrum a empresas grandes, tema que se está (y en el que estamos) haciendo en muchas organizaciones….
Scrum a gran escala (Large-scale scrum)
Esta es una iniciativa de Craig Larman, a los antiguos del blog os sonará por un post de críticas a CMMI, por el post de los patrones GRASP o por ser el autor de el en sus tiempos popular libro de UML y patrones.
Recientemente, se ha metido en el tema de Scrum en empresas grandes con su ahora muy mencionado Scrum a gran escala (Large-scale scrum). Aquí tienes más información.
Large-scale Scrum trata mucho el tema de la organización de los product owner, que todos los que os hayais enfrentado a un Scrum en empresas grandes sabréis que es de los temas “candentes” y presenta algunas estructuras como la siguiente:
SAFe
La polémica SAFe, de la que vas a encontrar mucha opinión en contra, precisamente por lo que te comentaba al principio, por los temas de burocracia y sobre proceso al llevar agilidad a grandes empresas.
SAFe es unna metodología, más bien framework, creado por Dean Leffingwell.
Ya os dejé casi hace un año un resumen de SAFE, Scaled Agile Framework (SAFe), una metodología ágil para grandes empresas, así que no me extiendo más en ella.
Spotify Culture
Llevamos años siguiendo la evolución de Spotify hacia la agilidad, siendo más de 250 personas. Ya hace un par de años te hablé de ello, en el Caso de estudio de Como Spotify organiza, de manera ágil, su departamento de desarrollo software.
En este caso más que un propósito de “metodología” hablamos de un conjunto de consejos de la aplicación de la agilidad (más allá de Scrum) en Spotify.
Desde que decidieron hacer públicas sus evoluciones son muchos los documentos y experiencias que puedes, debes, leer. Cómo el pdf que te dejaba en el anterior post que te referenciaba o el último video sobre la Spotify culture.
Spotify Engineering Culture – part 1 from Spotify Training & Development on Vimeo.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Javier,
buen artículo del estado del arte/práctica.
Las situaciones donde se debe escalar la agilidad, más allá del escenario «de manual» de un equipo pequeño con un único producto, requieren algún tipo de organización y coordinación siguiendo patrones más o menos centralizados como los que expones.
Me gustaría hablar sobre esto en la próxima Conferencia Agile Spain de Barcelona. También me gustaría conocerte allí si vas. 🙂
Àlex Ballarin
Gracias Álex, si acaso fuese nos vemos allí!
Buenas, este tema me resulta muy interesante, sobre todo porque veo que sería la gran demostración de lo positivo que es en la práctica (grande). Por otro lado agradecería si alguien pudiera darme referencias de implantación de metodología ágil en la administración pública española. Como Trabajo de Fin de Grado para la UCAM (Murcia) estoy trabajando este asunto a modo de laboratorio en el Departamento de Informática del Ayuntamiento de Chiclana (Cádiz).
gracias
Hola Arturo,
en la Administración Española no las conozco (habrá pioneros, pero soy pesimista en conjunto). En la CAs 2014 estuve en una charla de Jerónimo Palacios donde nos explico sus experiencias en el Gobierno Británico.
Echale un vistazo a estas webs:
+ https://www.gov.uk/service-manual/agile
+ https://digitaltransformation.blog.gov.uk
+ https://www.gov.uk/service-manual/operations/devops.html
Saludos,
Alex Ballarin @ http://www.itnove.com
Muchas gracias Alex.