El pasado otoño visité algunas de las empresas tecnológicas más importantes de Silicon Valley (PayPal, Twitter, Salesforce, Wallmart.com, etc.). En primer lugar, la gente, sobre todo la dirección, quería saber cómo escalar sus implementaciones Scrum; y en segundo lugar, los equipos no estaban haciendo pruebas dentro del Sprint.
A mediados de febrero vuelvo al Valle para impartir un curso de CSM y CSPO así como un curso de Taller de ampliación y pienso abordar estas dos cuestiones de frente.
Escala: Cada día aparecen en línea más marcos de escalado. La mayoría me parecen demasiado prescriptivos y limitados en su eficacia. Sin embargo, marcos como SAFe son un buen punto de partida para empresas con implantaciones muy recientes.
Es importante recordar que Scrum se diseñó para escalar. La primera vez que escalé equipos Scrum en IDX a mediados de los 90 quedó realmente claro. Scrum se basa en una arquitectura modular u orientada a objetos. Permite que varios equipos trabajen simultáneamente en todos los módulos sin efecto dominó. A esto se le llama todo a la vez-Scrum y fue el modelo de equipo que Nonaka y Tachieuchi destacaron en su artículo de HBR el que inspiró el Scrum. Una empresa Scrum realmente eficaz debe tener un diseño modular. El equipo Scrum Inc. ha desarrollado un marco escalonado que permite a las empresas conectar y desconectar los módulos que necesiten en función de su contexto específico.
¿Cuál es su contexto? ¿Pertenece usted a una gran industria madura, como un contratista gubernamental? ¿O es una empresa de software de éxito que siente que la innovación le pisa los talones? En función de su visión, sus necesidades y su sector, probablemente querrá dar prioridad a determinados aspectos de la ampliación antes que a otros.
Prueba dentro del Sprint: Posiblemente, el aspecto más importante de Scrum es el ciclo de retroalimentación. Al final del Sprint, el equipo muestra el software a todas las partes interesadas. Las partes interesadas lo prueban y dan su opinión al equipo sobre posibles mejoras. La mejora continua es realmente el objetivo final, así que sin un software que funcione, el proceso Scrum se viene abajo.
Tiene que funcionar para recibir comentarios. No sabrás si funciona hasta que lo pruebes.
Si no realizas las pruebas dentro del Sprint, no obtienes feedback de tus clientes y partes interesadas en la Revisión del Sprint. Esa información es necesaria para evaluar lo que les gusta y lo que no, y para realizar cambios con prontitud.
Probar es difícil y muchos equipos no sienten que tienen el conjunto de habilidades o la oportunidad de probar dentro del Sprint. Incorpore probadores al equipo. Utilice herramientas listas para usar y desarrolle un régimen de pruebas gradual. Con objetivos claros y un equipo motivado y centrado, las pruebas pueden realizarse antes de la revisión.
-- Jeff Sutherland
Spanish 
English 
French