Estudio de caso Scrum@Scale

Resumen

Imagina coger un libro y sentir que el autor podría haber sido una mosca en la pared en tus reuniones de equipo, o en tu sala de juntas: que los retos experimentados y abordados en el libro son los mismos retos a los que tú te enfrentas como líder de tu organización. Eso es exactamente lo que ocurrió cuando el líder de una empresa de servicios financieros con una tasa de crecimiento interanual del 24% recogió "Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo".

Esta organización no tenía problemas. Aparecían sistemáticamente en la lista de las 5000 empresas de más rápido crecimiento de Estados Unidos. No buscaban un rescate, sino continuar su gran trayectoria creando una transformación proactiva.

Cómo empezar
Como primer paso, Alex y su equipo visitaron la organización. Hablaron con los equipos de cara al cliente y con la dirección, que tenían su sede en un estado, y luego fueron a los equipos de software situados en otro estado. Comprobaron que la afirmación inicial era correcta: la organización no sólo era fuertemente Waterfall, sino casi Anti-Agile; de hecho, los analistas de negocio tenían prohibido hablar con los desarrolladores de software.  

Alex y su equipo comenzaron el compromiso trazando un mapa de los diferentes procesos de la cadena de valor. Esto les permitió identificar su mayor cuello de botella y la mejor oportunidad de intervención: los equipos de software de Florida. Decidieron que éste era el mejor lugar para poner en marcha su modelo de referencia. Consiguió que se organizaran en 6 equipos interfuncionales y empezó a hacer Scrum en Sprints de 1 semana. Muchos de los analistas de negocio se convirtieron en Scrum Masters y el equipo de producto en Product Owners.

En cuanto el modelo de referencia comenzó a utilizar Scrum, empezaron a surgir preocupaciones culturales. Había confusión sobre dónde recaía la logística al utilizar Scrum. Los directivos que estaban acostumbrados a definir su autoridad por los que les reportaban se sentían perdidos y temían por la seguridad de sus funciones. Había una capa de jefes de departamento acostumbrados a controlar el presupuesto, la contratación y las vacaciones. Esto no se planteó al discutir el cambio a Scrum porque era un área que la empresa no quería cambiar. Aprender esto por las malas puso de manifiesto la necesidad de una mayor transparencia y comunicación.

Resultados clave

A pesar de los retos, los resultados de la encuesta de la empresa mostraron una gran mejora después de sólo 8 Sprints. La Adecuación de la Comunicación mejoró de 1,9 a 3,6 en la escala de 5 puntos. La priorización pasó de 1,7 a 4,1 y la transparencia mejoró de 2,0 a 3,9. Además, los equipos fueron capaces de entregar cada semana mucho más valor que antes. Los equipos de diseño cuadruplicaron su velocidad y rendimiento y los equipos de código heredado duplicaron los suyos. Quizás lo más impresionante fue el hecho de que este aumento de la velocidad permitió a los equipos centrarse en remediar la deuda técnica que se estaba acumulando y mejorar significativamente la calidad del trabajo entregado. Antes de adoptar Scrum, el equipo de equipos tenía un retraso de 100 errores y crecía constantemente. Tras 8 semanas de uso de Scrum, la acumulación de errores se redujo a sólo 17 y se redujo, una mejora de la calidad de 83% en sólo dos meses.

Lecciones aprendidas

Se trata de resultados notables, y quizás lo más impactante sean las lecciones aprendidas en el camino. Así que, recuerda, el entusiasmo no es la preparación. Como advierte Sheive, "mirar demasiado hacia delante en un gran cambio puede hacer que a veces olvides dónde estás y cuál es el siguiente paso". En su lugar, insta a los que participan en la transformación a formas de trabajo ágiles a "asegurarse de que sabes dónde empiezas. Profundiza en ello".

Las organizaciones que se plantean cambiar su forma de trabajar para conseguir una verdadera agilidad empresarial deben establecer una sólida comprensión de su punto de partida, teniendo en cuenta tanto las cosas malas que quieren cambiar, como las buenas que quieren mantener mientras la organización evoluciona. Y deben hacer que esto sea visible para los equipos. Como aconseja Sheive, "asegúrate de que todo el mundo tiene claro lo que va a cambiar y lo que no va a cambiar... especialmente para los directivos, o conseguirás fricciones y un vacío de especulación".

Quién es Alex Sheive

Alex es un Scrum TrainerScrum@Scale Trainer y Coach/Consultor en Scrum Inc. Su primer contacto con el desarrollo ágil de software fue en el año 2000 en Thoughtworks, donde tuvo la suerte de codearse con varios de los futuros autores del Manifiesto Ágil y desde 2008 ha utilizado Scrum para construir software, tanto como desarrollador principal como empresario. Ha descubierto que Scrum es transformador en proyectos que van desde los sistemas de riesgo financiero hasta las plataformas de juegos DIY. Alex es un nómada digital que ha viajado literalmente por todo el mundo, viviendo en nueve países diferentes y sólo se ha intoxicado en tres. Le gusta dar charlas sobre tecnología (2 veces presentador del SXSW) y asesorar a los emprendedores sobre el desarrollo de productos lean basándose en sus propios éxitos y fracasos.