Scrum Case

Por Luciano Osorio – Scrum Master en Zappts

Traducción Libre y Adaptada del texto Original Scrum Papers (páginas 45 a 47), escrito por Jeff Sutherland, Ph.D.

En 2005, Jeff Sutherland (uno de los creadores de la Metodología Scrum) trabajó con Peter Deemer en Yahoo!. Querían presentar Scrum a sus gerentes.

Después de que la gerencia decidió utilizar Scrum, se utilizó un análisis de productividad de su implementación en IDX Systems (ahora GE Healthcare) para calcular un ROI (return on investment) anual de 1000% en un período de tres años de uso de Scrum en Yahoo!.

Después de dos años de implementación en más de 100 equipos, la tasa de retorno de Yahoo! para su inversión en cada entrenador Scrum interno fue de US$1,4 basada en el entrenamiento de 10 equipos por año. Esto equivale a aproximadamente 1000% de ROI.

Los equipos entrenados por un entrenador Scrum lograron 3 a 4 veces las ganancias de productividad de los equipos que no fueron entrenados.

Scrum fue adoptado como herramienta de Transformación Digital tanto en Yahoo! como en GE Healthcare.

Aumento del ROI con Scrum

La tasa interna de retorno sobre la inversión en capacitación de Scrum es bastante alta. Al promediar todos sus equipos, muchas empresas duplicaron su tasa de producción de software.

Recientemente, una empresa de CMMI Nivel 5 redujo los costos de proyectos de software por la mitad. Además, hubo una reducción del 40% en los defectos medidos. Incluso con los recortes de costos, la empresa mantuvo el cumplimiento del Nivel 5 del CMMI para todos los proyectos.

Incluso las mejores empresas muestran mejoras radicales de rendimiento cuando comienzan a utilizar Scrum y logran mucho más del 1000% de retorno sobre la inversión en capacitación Scrum.

Este artículo aborda el retorno de la inversión en capacitación de Scrum para grandes empresas. Estas empresas tienen miles de empleados y cientos o miles de desarrolladores.

Estas empresas establecieron, a lo largo de muchos años, procesos pesados, burocráticos y llenos de fallas.

Aunque parezca fácil generar ganancias sustanciales simplemente eliminando las fuentes más obvias de ineficiencia, introducir un proceso radicalmente nuevo en toda la organización puede ser lento y doloroso.

Scrum tiene un proceso continuo y sistemático de mejora de calidad. Este proceso identifica y prioriza los impedimentos de las operaciones en el progreso de la empresa.

IDX Systems (ahora GE Healthcare): escalando Scrum por primera vez

Durante el verano de 1996, IDX Systems contrató a Jeff Sutherland como vicepresidente de ingeniería y desarrollo de productos. IDX tenía más de 4,000 clientes y era una de las empresas de software de salud más grandes de EE.UU. Eran cientos de desarrolladores trabajando en docenas de productos.

Esta era una oportunidad para extender Scrum al desarrollo a gran escala.

El enfoque en IDX fue organizar todo el grupo de desarrollo en un conjunto interconectado de Scrums.

Aunque este fue el primer equipo grande de desarrollo en intentar este enfoque, la estrategia ya había sido ejecutada muchas veces y documentada por Ken Schwaber en “Scrum in the Enterprise”.

Cada parte de la organización era basada en equipos, incluyendo el equipo de gestión. Tenía dos vicepresidentes, un arquitecto senior y varios directores. Los Scrums de primera línea se reunían diariamente.

Un Scrum of Scrums, que incluía a los líderes de cada equipo Scrum en una línea de productos, se reunía semanalmente. El Scrum de gestión se reunía mensualmente.

La principal lección en IDX fue que Scrum se adapta a cualquier tamaño.

Con docenas de equipos en operación, el problema más difícil era garantizar la calidad del proceso Scrum en cada equipo. Toda la organización tenía que aprender Scrum al mismo tiempo.

IDX era lo suficientemente grande como para traer especialistas en productividad para monitorear el rendimiento de cada proyecto.

Métricas de Escalabilidad

Mientras que la mayoría de los equipos lograron duplicar el número de Function Points por mes en comparación con el promedio de la industria, algunos equipos entraron en un estado hiperproductivo. Producían cuatro o cinco veces más funcionalidades entregables que el promedio de la industria. Estos equipos se convirtieron en estrellas de la organización y ejemplos a seguir.

Uno de los equipos más productivos de IDX fue el equipo de Web Framework. Creó una infraestructura de front end web para todos los productos. La infraestructura fue diseñada para alojar todas las aplicaciones de IDX, además de interoperar perfectamente con aplicaciones de usuario final o de terceros.

El Web Framework fue creado por un equipo distribuido, con desarrolladores en Boston, Seattle y Vermont, que se reunían diariamente por videoconferencia.

La transparencia geográfica de este modelo produjo equipos distribuidos con un rendimiento tan alto como el de los equipos co-localizados. Esta se convirtió en la característica más distintiva de los Scrums hiperproductivos distribuidos/tercerizados de las empresas Xebia en Holanda e India, y Exigen Services en Estados Unidos y Rusia.

La calidad del software de muchos de los equipos hiperproductivos de Scrum puede ser extraordinariamente alta.

El Web Framework de IDX fue implementado por primera vez en 1997. En 2007, fue seleccionado como la principal tecnología web para los sistemas de GE Healthcare.

Sin embargo, muy pocos equipos de software de IDX alcanzaron el estado hiperproductivo.

En promedio, basado en el análisis de Function Points realizado por la empresa de Capers Jones, Software Productivity Research, IDX solo alcanzó un promedio de ganancias de productividad de 240%. La principal razón fue la caída de productividad causada por el exceso de miembros en los equipos Scrum, con hasta 15 personas.

Hoy es conocimiento común que los equipos grandes causan una pérdida significativa de productividad e impiden la escalabilidad lineal.

La escalabilidad lineal es una de las principales características de las implementaciones de Scrum bien ejecutadas.

Resumen de Ganancias de Productividad en IDX

El presupuesto de la organización de desarrollo de IDX era de casi US$ 50 millones por año. Esto era suficiente para un análisis detallado de la productividad basal antes de Scrum y las ganancias de productividad generadas por él.

Una firma de consultoría independiente fue contratada para realizar el análisis de Function Points de todos los softwares de IDX. Esta empresa se llamaba Software Productivity Research (SPR). Jeff Sutherland había trabajado con Capers Jones, el fundador de SPR, durante la creación de Scrum y quería comparar las metas de productividad proyectadas de Scrum con su desempeño real.

Algunos productos de IDX tenían más de 12,000 Function Points. Esto era equivalente a más de un millón de líneas de código en Java o C#. Los productos más pequeños tenían alrededor de 5,000 a 6,000 Function Points.

Las aplicaciones eran productos financieros y clínicos para operar hospitales y grupos médicos independientes en miles de sitios.

Las plataformas de implementación variaban desde Mumps hasta Cobol y Java, hasta las herramientas y lenguajes de Microsoft más recientes disponibles.

Function Points y Story Points

Function Points fueron elegidos como una medida estándar de la industria, independiente del lenguaje y entorno de desarrollo de software. Esto se hizo para garantizar una comparación realista de la productividad entre las tecnologías y equipos de desarrollo. También había garantía de comparabilidad con datos externos de la industria.

Especialistas externos fueron contratados para calcular Function Points, con el fin de proporcionar datos calificados para la investigación.

Como regla general, los Function Points no son fácilmente calculados por el equipo de desarrollo y no se recomiendan como una estrategia operativa.

Los Story Points surgieron como la mejor práctica de la industria para medir la velocidad del equipo de Desarrollo Ágil. Son fáciles de calcular y útiles para la planificación del lanzamiento de un software.

Sin embargo, no son comparables entre equipos o entre empresas. Por lo tanto, no eran adecuados para datos de investigación sobre la primera implementación de Scrum en una gran empresa.

En cada lanzamiento de cada producto, el número de Function Points fue recalculado para reflejar los nuevos recursos a través de las consultas de Software Productivity Research.

El aumento en Function Points fue dividido en meses por persona para los equipos de desarrollo sobrecargados. Esto incluye equipos de diseño, desarrollo, prueba, administrativa y de gestión.

La velocidad inicial de todos los equipos de desarrollo fue el promedio de la industria, en 2 a 3 Function Points por mes por equipo.

Algunos equipos aceleraron hasta alcanzar la hiperproductividad usando Scrum, logrando de 5 a 10 veces el rendimiento promedio de la industria. Estos equipos eran aproximadamente el 10% de la organización y alcanzaron un aumento promedio de productividad del 666%.

Un pequeño número de equipos (menos del 5%) presentó fallas por razones personales o técnicas.

Ganancias de Cada Equipo

Ocasionalmente, un equipo no era capaz de trabajar junto de manera eficaz y acababa siendo reorganizado o disuelto, generalmente durante el primer Sprint.

Con menor frecuencia, un equipo de alto rendimiento había asumido un riesgo calculado en nuevas tecnologías (siempre aprobadas por la gerencia) y la falla técnica de algunos Sprints era anticipada (incluso incentivada) para obtener un liderazgo tecnológico en el mercado.

No hubo fallas en proyectos grandes, solo fallas en la entrega de software en Sprints aislados o en una corta serie de Sprints. En caso de fallas del equipo, los equipos siempre fueron reconstruidos. En caso de fallas técnicas, los esfuerzos se duplicaron en los Sprints siguientes para superar los desafíos de investigación y desarrollo.

El 85% restante de los equipos logró una velocidad promedio de 5 a 6 Function Points por mes por equipo, teniendo una ganancia promedio del 100%. La ganancia neta de productividad de todos los equipos combinados fue del 240%.

Esto fue visto como un fracaso para alcanzar un rendimiento comparable al nivel de Toyota. Sin embargo, fue un buen comienzo para la implementación de Scrum en toda la empresa. Recientemente, los equipos de desarrollo de tamaño comparable han logrado consistentemente más de 10 Veces la Velocidad Promedio de la Industria.

Todos los Equipos de una Organización Entera Fueron Hiperproductivos, alcanzando el objetivo original de Scrum.

Conclusión

Es importante enfatizar que estas ganancias de productividad se lograron a un ritmo sostenible. Hubo mayor retención de empleados y mayor capacidad para contratar a las mejores personas. Esto se debe al ambiente de trabajo de alta calidad proporcionado a los desarrolladores por el uso de Scrum.

Los equipos hiperproductivos siempre fueron los equipos más entusiastas, que amaban sus trabajos y trabajaban con gran sinergia, como un equipo deportivo profesional.

La hiperproductividad no se logra trabajando más arduamente, sino trabajando con más eficacia a través de comunicación intensa, apoyo mutuo y una habilidad “sin esfuerzo” que hace que las cosas difíciles parezcan fáciles.

Piensa en Michael Jordan subiendo para un “shot” de baloncesto. El equipo trabajó para que el juego fuera propicio para el “shot,” lo que a menudo hace que parezca tan suave y fácil que genera alegría tanto en los jugadores como en los espectadores.