¿Qué son los ScrumButs o ScrumPeros?

Hay empresas que para tomar su camino hacia la Agilidad adoptan Scrum, y otras, adaptan Scrum. Adaptar Scrum para pasar de scrum técnico, basado en reglas, a scrum avanzado y así aplicar directamente principios de gestión ágil con el conocimiento y experiencia de los equipos, y con una cultura ya ágil en la organización, trata de la madurez en Agilidad. Pero adaptar Scrum de entrada sin una cultura ágil es cosa muy distinta... mi compañero Aníbal suele decir "cómo una empresa que está lidiando a duras penas con su producto en el mercado puede pretender diseñar una metodología"... en mejor de los casos se trata de organizaciones que hacen cambios a corto plazo para dar tiempo a corregir sus deficiencias.

¿Adoptar o no ScrumButs?

ScrumButs/Peros son malas prácticas por las que los equipos no pueden sacar el máximo provecho de Scrum para resolver sus problemas y hacer realidad los beneficios del desarrollo de productos con este marco. Cada rol de Scrum, artefacto, regla, y timebox se ha diseñado para proporcionar los beneficios descritos, y abordar problemas recurrentes predecibles. Normalmente los ScrumButs implican que Scrum ha puesto de manifiesto una deficiencia que está contribuyendo al problema, pero es demasiado difícil de solucionar. Un ScrumBut conserva el problema al modificar Scrum para que la deficiencia no sea visible y no se considere como problema del equipo.

Por ejemplo, la definición de hecho (DoD) podría no incluir inicialmente regresión y pruebas de rendimiento, ya que tomaría varios meses desarrollar las pruebas automatizadas. En este caso durante los meses sin pruebas automatizadas el desarrollo estará penalizado por una deuda técnica, y esta se debe de restaurarse tan rápidamente como sea posible.

Un ScrumBut tiene la siguiente sintaxis:

(ScrumBut) (Razón) (Workaround)

Un ejemplo ScrumBut:

• Estamos haciendo Scrum, pero las retrospectivas no son eficaces, por lo que sólo las hacemos cada tres meses.

Las retrospectivas a menudo son ineficaces porque no se hace nada acerca de las cuestiones planteadas, es más probable que el equipo necesite mejores retrospectivas en vez de menos.

Otros ejemplos:

• Estamos haciendo Scrum, pero nuestros clientes e interesados están demasiado ocupados para asistir a las revisiones de sprint, por lo que dejamos de hacerlas.
• Estamos haciendo Scrum, pero no conseguimos acabar los incrementos en dos semanas, por eso ahora dejamos que nuestros sprints sean abiertos sin duración fija.
• Estamos haciendo Scrum, pero a veces nuestros gerentes nos dan tareas "especiales", por lo que no siempre tenemos tiempo para cumplir con la definición de hecho (DoD) .

¡Esto NO es Scrum!

Hay una página en la que se puede hacer un test de ScrumButs, lo interesante es que muestra la distribución en tarta de los diferentes ScrumButs aplicados con mas frecuencia.

En general los expertos en Scrum nos oponemos a los ScrumButs porque casi siempre esconden un impedimento o deficiencia que, de ser abordado y eliminado, mejoraría muchísimo las cosas. Mi consejo es preguntar en primer lugar por el porqué, a veces hay que escalar la pregunta hasta llegar a la causa raíz, y es usual llegar a respuestas como "como siempre se ha hecho así..." resultando que si se puede cambiar y por tanto hemos adoptado un ScrumBut sin necesidad. En segundo lugar mi consejo es "adoptar antes de inspeccionar y adaptar".