Guía Scrum | 16. Scrum escalable

El Equipo Scrum debe constar de hasta diez personas. Pero, ¿qué hacer cuando un grupo más grande de especialistas necesita trabajar en un proyecto? ¿O si la organización decide seguir una forma ágil de gestión? Para resolver este problema, los desarrolladores de Scrum propusieron [email protected] Es una arquitectura libre de escala para organizar equipos completos de acuerdo con los principios de Scrum.

Scaling Scrum – tabla de contenidos:

1. Introducción
2. [correo electrónico protegido]
3. El scrum de scrums
4. Más problemas de escalado y [email protected]
5. Resumen

Introducción

Tan pronto como crece una organización, aparecen nuevos tipos de problemas. Por ejemplo, una caída en la eficacia de los empleados causada por una estructura interna compleja, una toma de decisiones o un establecimiento de dirección difíciles. Las empresas que operan ágilmente a nivel de equipo de proyecto pequeño a menudo buscan escalar.

A muchas empresas les va bien sin escalar Scrum. Incluso si muchos Equipos Scrum se ejecutan simultáneamente, no necesitan coordinación ya que los grupos operan de forma independiente. Sin embargo, esto no significa que sea un Scrum multi-equipo. La necesidad de escalar surge solo cuando la mayor parte de la organización está trabajando en un producto y puede sincronizar sus múltiples Equipos Scrum de manera efectiva.

La mayoría de las organizaciones que adoptan métodos de gestión ágiles a escala eligen el modelo SAFE o Scaled Agile Framework. Sin embargo, hoy no nos centraremos en SAFE , sino que hablaremos de un modelo diferente llamado [email protected] , ya que, según el 15.° informe State of Agile de 2021, es la segunda mejor opción entre las empresas que optan por ágil.

[correo electrónico protegido]

En 1996, los creadores de Scrum, Jeff Sutherland y Ken Schwaber, estaban trabajando en un gran proyecto. Mientras lo hacían, tenían problemas para mantener sincronizados a los equipos más pequeños que trabajaban en Scrum. Se les ocurrió una forma de escalarlo, que finalmente llamaron [email protected]

Análoga a la Guía oficial de Scrum fue la Guía [email protected] , que define esta forma de escalar el trabajo como:

Un marco dentro del cual operan las redes de Equipos Scrum siguiendo la Guía Scrum para resolver problemas adaptativos complejos y entregar productos de manera creativa con el mayor valor posible.

La premisa básica de [email protected] es la simplicidad y la eficiencia. Por tanto, su funcionamiento se basa en una arquitectura libre de escala. En otras palabras, usa Scrum para escalar Scrum. De esta forma, un equipo Scrum compuesto por individuos que actúan como Product Owner, Scrum Master o Developer se convierte en el Scrum de Scrums: un equipo formado por equipos.

El scrum de scrums

Scrum of Scrums es un equipo de scrum con personas que asumen los roles tradicionales de Scrum. Sin embargo, dado que la tarea de Scrum of Scrums es integrar los resultados del trabajo de varios Equipos Scrum, necesita publicaciones adicionales:

• Equipo de propietarios de productos : un grupo de propietarios de productos que se reúnen para acordar prioridades y crear una visión cohesiva del producto.
• Propietario principal del producto: propietario del producto del equipo Scrum o una persona que se ocupa exclusivamente del Scrum de Scrums.
• Scrum of Scrums Master : la persona que supervisa la eficacia del Scrum of Scrums.

Se reúnen en los mismos eventos de Scrum y usan artefactos similares.

Más problemas de escalado y [email protected]

La arquitectura sin escala de [email protected] significa que permite escalar más de una vez. Si una organización necesita coordinar equipos a una escala aún mayor, puede configurar Scrum of Scrums.

Sin embargo, escalar Scrum, como cualquier otra metodología de gestión, tiene sus defectos, y en este caso, son similares a los de los Equipos Scrum básicos, solo que son proporcionalmente mayores. Es por eso que recomendamos trabajar en los detalles de la colaboración dentro de cada Equipo Scrum antes de comenzar Scrum a mayor escala. Sugerimos escalar Scrum para equipos experimentados que tengan un buen conocimiento y comprensión de los valores y el funcionamiento de Scrum.

Escalando Scrum – resumen

Escalar Scrum no es un juego de niños. Requiere que los equipos Scrum apliquen con soltura los principios Scrum y sincronicen sus tareas con otros equipos Scrum. Por lo tanto, la pregunta básica a responder es: ¿Se necesita escalar? El hecho de que haya muchos equipos Scrum en una organización no significa automáticamente que coordinarlos traerá mejores resultados.

Si una organización elige aumentar Scrum, obtiene una arquitectura sin escala que se puede aumentar aún más con éxito. Sin embargo, cada aumento va acompañado de un aumento en el nivel de complejidad con el que deben lidiar el equipo del propietario del producto, el propietario principal del producto y el Scrum of Scrums Master.

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autora: Carolina Becker

Como Project Manager, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos