Hola!
Todos sabemos que Scrum es la solución a todos los problemas. En la página 12 de la guía de Scrum hay una frase que dice lo siguiente:
Scrum Hoch bIquv qay’ taS
Que traducido del Klingon viene a significar
Scrum es la solución para todo tipo de problemas
Y listo! Ahora bien, si analizamos los 3 pilares de Scrum: Transparencia, Inspección y Adaptación; los mismos nos indican que un equipo a medida que utiliza Scrum, aprende a ser más eficiente. La base de esta teoría es que el equipo sea independiente y tenga capacidad de autogestión.
Sin embargo, esto último también puede terminar con un efecto boomerang: Un equipo puede ir a peor ejecutando Scrum. Y es que, no todos las personas que trabajan en nuestro rubro cumplen con la premisa de “Scrum no es para aficionados”.
Es normal que un equipo, cuando comienza a gestionarse, los resultados no sean los esperados. Es ese punto donde la inspección y adaptación ayudan a que el equipo pueda comenzar a mejorar. Sin embargo, también existe la posibilidad de que un equipo nunca mejore. Que siempre el listón este muy bajo y que no exista un análisis interno de inspección y adaptacion. (Aclaración: en estos casos la transparencia suele estar cercana al 95% de opacidad)
¿Y qué hacer en estos casos? Una opción es volver a dar soporte al equipo, que popularmente lo comparo con criar niños de 3 años. Ayudar en cada paso, ser el facilitador, etc. Un poco de Scrum Master con el rol de padre. Y hasta aquí debes llegar, luego de un par de Sprints es momento de volver a evaluar si el equipo es autosuficiente. En caso contrario … pues cambia el equipo.
Es una pena, sin embargo la motivación con la que algunas personas llevan adelante su trabajo no es la misma que la que tienen otras. Y en el caso de los trabajos con tecnología esta motivación suele ser intrínseca, con lo que los “premios a corto plazo” son una tapadera muy poco productiva.
Una forma de explicar esto es la práctica de “El que rompe la build pone 1€ en un frasco”. El objetivo de práctica no es asustar para que los developers se desangren poniendo miles de €uros (yo lo he hecho), ni tampoco es recaudar para las cervezas de los jueves (también lo he hecho). Esta práctica implica un trabajo de fondo, donde cada persona es suficientemente consciente de que la calidad no es opcional y de que romper la build es detener el equipo en marcha. Y esto es suficiente, muchas personas lo entienden, otras lo ven como una gracia.
Asi que bien, Scrum puede servir para que los equipos aprendan a autogestionarse y a mejorar sprint a sprint; y también sirve para detectar equipos que no poseen ganas de mejorar y .. bueno que tal vez sea necesario cambiar.
Scrum Guide: https://www.scrum.org/Scrum-Guide
Scrum no es para aficionados: http://elbruno.com/2013/12/24/scrum-scrum-no-es-para-aficionados/
Saludos @ Home
El Bruno
 |
 |
 |
Archivado en: ALM, Scrum
