Hoy me han estado hablando de un proyecto que aparentemente utiliza SCRUM. En la propuesta comercial se ha vendido como metodología, y a los desarrolladores se les ha comentado que usan Scrum. He oido anécdotas bastante sorprendentes y me gustaría realizar mis primeras prácticas como Scrum Master aunque sea desde las sombras.
- Caso: El jefe de proyecto ha llamado a primera hora para suspender la reunión de seguimiento diaria (Daily stand up meeting o Daily Scrum). No iba a poder asistir
- Refactor: La base es el equipo, y la comunicación entre el mismo. Si el jefe de proyecto no puede asistir, el equipo debería seguir con la reunión. Sobretodo bajo el concepto de que un equipo de Scrum es autogestionado. Es más, debería aplicar la pertinente penalización a la persona que no ha asistido (flexiones, monedas en el bote, etc.) Otra cosa es que el Jefe de Proyecto haga las veces de Scrum Master (creo que en un proceso de adaptación de roles ese debería ser el rol del perfil). En ese caso me pregunto si se puede realizar un Daily Scrum sin Scrum Master. Es una gran pregunta que realizaré en los foros de Agile Spain, porque no tengo la respuesta.
- Caso: El proyecto tiene los perfiles de Jefe de Proyecto, Analista Funcional, y luego están los desarrolladores.
- Refactor: Habría que comentar que la traducción al castellano de Scrum es "Melé". Los equipos ágiles son equipos planos, sin roles jerárquicos.
- Refactor 2: La figura de analista funcional desaparece. Ese es un rol típico del diseño en cascada (Waterfall). Se profundiza en las defiiniciones funcionales antes de cada sprint.
- Caso: Me contaban que en una reunión para tomar una decisión de rediseño de la base de datos no permitieron la entrada al desarrollador responsable de la reimplementación.
- Refactor: las decisiones de arquitectura y diseño se realizan con todo el grupo, bajo el concepto de que la masa sabe más que el experto.
- Casos de estudio pendientes: me gustaría informarme sobre si se utiliza TDD para el desarrollo. Otras prácticas de XP como el trabajar 8 horas o el Pair Programming ya se que no. Me falta información sobre qué prácticas si se realizan para saber el grado de aproximación a Scrum.
Esto no pretende ser una crítica, sino un ejercicio de mejora, ya que cuesta implantar una metodología. Y cuesta mucho más seguirla después. En alguna ocasión he comentado que Ágil no quiere decir desorganizado. Las metodologías ágiles son incluso más rígidas que las tradicionales, en búsqueda de la calidad.
Solo espero que no piensen que los resultados del proyecto, el grado de satisfacción del cliente y sobretodo el del equipo se deban al uso de Scrum. Básicamente porque Scrum no se utiliza.
