Estudio de caso Scrum@Scale

Sistemática: De lo bueno a lo grande

Reforzar la definición de "Listo" para los elementos del Product Backlog ayudó a Systematic a duplicar la eficacia de su proceso.

"Los sistemas se pueden medir y los datos magnifican el aprendizaje. Hay que prestar mucha atención a la dimensión humana porque un mal uso de los datos destruirá la productividad."
- Carsten Jakobsen y Jeff Sutherland

RESUMEN DEL ESTUDIO DE CASO

Trainer Nombre: Carsten Jakobsen
Organización: Sistemática
Tamaño de la organización: Grande
Industria:
 Desarrollo de software
Tema Descomposición y refinamiento de la cartera de pedidos, Product Ownership
La fecha: 2009
Sitio web: https://agileeducation.org/trainer/carsten-jakobsen/

Resumen

En 2009, el Scrum@Scale Trainer Carsten Jakobsen comenzó a trabajar con Sistemáticauna gran empresa internacional de desarrollo de software. Al recopilar algunos datos iniciales relativos a los patrones de alto rendimiento en la empresa, se dio cuenta de que dos proyectos en particular rendían dos o tres veces más que el resto. En este estudio de caso, Carsten demuestra la importancia del patrón de preparación, y de las medidas relacionadas con la eficiencia del proceso, para llevar a los equipos a un nivel de rendimiento superior.

Iniciar el Scrum@Scale desde una línea de base alta

Systematic es un sólido integrador de sistemas y software con clientes en más de 50 países y más de un millón de usuarios en todo el mundo. Sus principales áreas de negocio son el sector público, la sanidad, la defensa, la inteligencia y la seguridad nacional, y la gestión de la información. Según un libro blanco preparado conjuntamente con el fundador de Scrum, Jeff SutherlandSystematic tiene una certificación de nivel cinco del Modelo de Madurez de las Capacidades (CMMI).

En 2009, la plantilla de Systematic, altamente cualificada (62% tienen titulación superior) de 1.000 personas, llevaba dos años utilizando Scrum. Por ello, Carsten quería entender, tanto en términos cualitativos como cuantitativos, cómo los dos equipos de Scrum de alto rendimiento lo estaban haciendo tan bien, incluso teniendo en cuenta la fuerte base de Scrum en la organización.

Comprender el concepto de "listo"

Desde el punto de vista cualitativo, descubrió que los dos equipos de alto rendimiento se enfrentaban a retos, realizaban retrospectivas detalladas y, en general, dedicaban tiempo a investigar lo que habían hecho una vez que lo habían hecho. Cuantitativamente, quería entender cómo tomar el aprendizaje de estos dos equipos y llevar este rendimiento a los otros tres equipos en consideración.

Descubrió que estos dos equipos, etiquetados como A y E, tenían una productividad media de 140-192% y 258-365%, respectivamente. Lo que Carsten descubrió fue que, en ambos casos, el Scrum Master del equipo no permitía que el trabajo entrara en un Sprint cuando aún no estaba "Listo". Así, cuando un Product Owner se presentaba con un trabajo que era más una idea que una tarea concreta, el Scrum Master le pedía al Product Owner que refinara la idea hasta el punto de que los miembros del equipo Scrum pudieran dividir la idea en una paleta de tareas discretas y ejecutables. Para trasladar este aprendizaje a otros equipos, existe una lista de comprobación para determinar cuándo una idea está lista para entrar en un Sprint (se puede encontrar un ejemplo en el libro blanco).

Los resultados del patrón listo

La noción de flujo de implementación de historias es una medida de la productividad de un equipo. He aquí un ejemplo de esta medida. Si una historia tiene dos días de esfuerzo para implementarla y tiene cinco días de duración del calendario para completarla, entonces el flujo de implementación de la historia es 40%, es decir, es la relación entre el esfuerzo de implementación proyectado y la duración del calendario de implementación. Carsten descubrió que, antes de que los SM insistieran en que sólo las tareas listas entraran en un Sprint, el flujo medio de implementación de historias de los equipos era de 23%. Y, después de que sólo entraran en un Sprint las tareas Preparadas, los equipos promediaban un flujo de implementación de historias de 55%.

Incluso cuando Systematic pasó de ser una empresa de 500 a 1.000 personas (entre los años 2014 y 18), la eficacia de su proceso se mantuvo estable con un alto flujo y productividad. Un análisis del trabajo resultante de sólo las tareas Ready que entraban en un Sprint mostró una mayor satisfacción del cliente con el producto y también una mayor satisfacción del equipo. Los proyectos pueden seguir el ejemplo de estos aprendizajes documentando su práctica en una lista de control de Listo y asegurándose de que las características se preparan adecuadamente antes de que se descompongan en historias comprometidas en un Sprint.

 

 

Más estudios de caso

The App That Scrum@Scale Built – Andrew Lin

La aplicación que construyó Scrum@Scale - Andrew Lin

Descubre cómo Registered Scrum@Scale Trainer Andrew Lin llevó a Biji, uno de los mayores portales web de deportes de Taiwán, a crear una nueva App para Cartoon Network Taiwán... pero con la advertencia de que la empresa de desarrollo utilizara el framework Scrum@Scale. Biji era nuevo en el mundo de las Apps y no estaba familiarizado con Scrum, pero Andrew Lin se puso manos a la obra y el equipo de desarrollo dio un paso adelante para hacerlo realidad.