Checklist para Scrum Masters
Un buen Scrum Master puede ocuparse de dos o tres equipos a la vez. Si te conformas con limitar tu rol a organizar reuniones, hacer cumplir los plazos y resolver los problemas del equipo, el rol de Scrum Master puede funcionar a tiempo parcial. El equipo seguramente superará las expectativas que existían en tu organización en los tiempos anteriores a Scrum, y lo más probable es que no se produzcan grandes catástrofes.
Pero si puedes imaginarte un equipo que disfrute logrando cosas que antes se creían imposibles, entonces también deberías tener la voluntad de ser un excelente Scrum Master.
Un excelente Scrum Master solo puede ocuparse de un equipo a la vez.
Especialmente para la fase inicial, recomendamos un Scrum Master motivado y comprometido para un equipo de aproximadamente siete personas.
Si aún no tienes una visión general de todo el trabajo que hay que hacer, intenta aprender más sobre el Product Owner, el equipo, los métodos de desarrollo del equipo y la organización en su conjunto. Aunque no existe una receta mágica, he enumerado algunas cosas a las que un Scrum Master debería prestar atención:
Checklist del Scrum Master para el Product Owner
Puedes aumentar la efectividad del Product Owner ayudándole a gestionar el Product Backlog y el plan de releases. (Recuerda que solo el Product Owner debería priorizar el Backlog.)
¿Corresponde la priorización del Product Backlog a las reflexiones y expectativas más recientes del Product Owner?
¿Se han incluido todos los requisitos y deseos de todos los stakeholders en el Backlog? Recuerda que el Backlog puede cambiar constantemente.
¿Tiene el Product Backlog un tamaño manejable? Para mantener un número de elementos que se pueda gestionar bien, los elementos detallados deberían estar en la parte superior del Backlog y los temas más generales más abajo. Es contraproducente entrar en demasiado detalle en más elementos que los de la parte superior, ya que los requisitos cambiarán permanentemente con la evolución del producto y el intercambio constante con clientes/stakeholders.
¿Hay requisitos (especialmente los de la parte superior del Backlog) que podrían escribirse mejor como User Stories independientes, negociables, valiosas, estimables, pequeñas y comprobables (criterios INVEST)?
¿Has informado a tu Product Owner sobre la deuda técnica y cómo evitarla? Puede ser útil añadir pruebas automatizadas y refactoring a la Definition of Done de cada elemento del Backlog.
¿Es el Backlog visible como fuente de información para todos los stakeholders?
¿Tienes una herramienta automatizada para gestionar el Backlog? Y si es así, ¿realmente te aporta valor? Estas herramientas conllevan el riesgo de que sea difícil encontrar la información buscada si el Scrum Master no comunica activamente esa información.
¿Puedes ayudar a comunicar la información imprimiendo y distribuyendo los datos a todos los involucrados?
¿Puedes ayudar a comunicar esta información creando gráficos y diagramas grandes y bien visibles?
¿Has ayudado al Product Owner a dividir los elementos del Backlog en releases adecuados? (Por ejemplo, en trabajos actuales (Front Burner), trabajos pendientes (Back Burner) y elementos que se incluyeron en el Backlog pero aún no se han preparado (Fridge).)
¿Saben todos los stakeholders (incluido el equipo) si el plan de release – medido según la Velocity actual (p. ej., Story Points por Sprint) – sigue correspondiendo a la realidad?
¿Ha actualizado el Product Owner el plan de release después del último Sprint Review? Pocos Product Owners que entregan productos suficientemente probados a tiempo actualizan el plan de release en cada Sprint. A menudo posponen algunos trabajos a futuros releases cuando surgen trabajos más importantes. Prueba con los Burndown Charts de Producto/Release según Mike Cohn, que puedes presentar a todos los involucrados después de que en los Sprint Review se confirme que los elementos están „done”. En ellos se pueden detectar fácilmente cambios tempranos en el alcance o el cronograma.
Checklist del Scrum Master para el equipo
1.) ¿Están los miembros del equipo en estado de „Flow” la mayor parte del tiempo? Algunas características de este estado son: Objetivos claros (las expectativas y reglas son reconocibles; los objetivos son alcanzables y corresponden a las habilidades de cada persona); Concentración y enfoque (focalización en un punto específico); Incertidumbre reducida (acción y conciencia se fusionan); Se pierde la noción del tiempo (la percepción subjetiva del tiempo cambia); Feedback directo e inmediato (los éxitos y fracasos durante la acción son reconocibles, por lo que el comportamiento puede ajustarse si es necesario); Equilibrio entre habilidades y desafío (no es ni demasiado difícil ni demasiado fácil); Un sentido de control personal sobre la situación/acción (la acción es intrínsecamente gratificante y, por tanto, se realiza sin esfuerzo).
1.) ¿Parece que los miembros del equipo se llevan bien entre sí? ¿Hacen actividades juntos? ¿Celebran los éxitos de sus compañeros?
2.) ¿Se aseguran los miembros del equipo de que todos mantengan los altos estándares? ¿Se animan mutuamente a mejorar?
3.) ¿Hay problemas u oportunidades de las que el equipo no habla porque no se sienten lo suficientemente cómodos? Puedes consultar a un profesional que te ayude a hacer más cómodas las conversaciones difíciles. (O lee más sobre el tema en el libro Crucial Conversations: Tools for Talking When Stakes are High)
4.) ¿Has probado ya diferentes formatos y lugares para tus Sprint Review Meetings? Algunas ideas se encuentran en el libro Agile Retrospectives: Making Good Teams Great de Esther Derby y Diana Larsen.
5.) ¿Se ha atenido el equipo a los criterios de aceptación? Quizás necesites revisar durante el Sprint los criterios de aceptación de los Product Backlog Items de ese Sprint.
6.) ¿Refleja el Sprint Backlog realmente lo que el equipo está trabajando actualmente? Las interrupciones y distracciones que no contribuyen a lograr el objetivo del Sprint son impedimentos.
7.) ¿Están las estimaciones de las tareas y el tablero de tareas actualizados?
8.) ¿Son los artefactos para la autogestión del equipo (tablero de tareas, Sprint Burndown Chart etc.) bien visibles, prácticos y útiles para todo el equipo?
9.) ¿Están estos artefactos suficientemente protegidos del micromanagement?
10.) ¿Se ofrecen los miembros del equipo voluntariamente para determinadas tareas?
11.) ¿Se han incluido en el Backlog elementos para pagar la deuda técnica (para resolver problemas que afectan la Velocity) o al menos se ha hablado de ello con el Product Owner?
12.) ¿Dejan los miembros del equipo sus títulos de trabajo fuera de la sala del equipo?
13.) ¿Se siente el equipo completo responsable de las pruebas, documentación de usuario, etc.?
Checklist para el desarrollo del producto
1.) ¿Tiene tu sistema en desarrollo un botón „Push-to-test” para que cualquiera (del mismo equipo o de otro) pueda comprobar fácilmente si ha roto algo? Esto se logra normalmente con el framework xUnit (JUnit, NUnit, etc.).
2.) ¿Tienes un equilibrio adecuado entre pruebas de sistema end-to-end automatizadas (pruebas funcionales) y pruebas unitarias automatizadas?
3.) ¿Escribe el equipo tanto „pruebas funcionales” como pruebas unitarias en el lenguaje del sistema que desarrollan (en lugar de lenguajes de scripting propietarios o herramientas de captura y reproducción que solo una pequeña parte del equipo sabe manejar)? ¡Es posible!
4.) ¿Ha descubierto tu equipo la zona gris extremadamente útil entre las pruebas de sistema y las pruebas unitarias?
5.) ¿Un servidor de integración continua alerta automáticamente en menos de una hora (o algunos minutos) cuando alguien ha causado un error de regresión?
6.) ¿Se acumulan todas las pruebas en el resultado del servidor de integración continua?
7.) ¿Han descubierto los miembros del equipo las ventajas del diseño evolutivo (Continuous Design) y el „refactoring despiadado” como alternativa al Big Design Upfront (BDUF)? Refactoring tiene una definición clara: cambiar la estructura interna de un sistema sin alterar el comportamiento observable externamente. Ante código redundante, lógica compleja, mala convención de nombres, acoplamiento excesivo entre objetos, etc., el refactoring debería realizarse varias veces por hora. Una cobertura de pruebas automatizadas es muy buena como red de seguridad para el refactoring. Las brechas en la cobertura de pruebas y el refactoring pospuesto son enfermedades que también se llaman deuda técnica.
8.) ¿Incluye tu Definition of Done para cada Product Backlog Item funcional una cobertura de pruebas completamente automatizada y refactoring? Es poco probable que puedas desarrollar un producto potencialmente entregable en cada Sprint sin aprender métodos de eXtreme Programming (como los descritos por Kent Beck, Ron Jeffries, etc.).
9.) ¿Trabajan los miembros del equipo mayoritariamente con Pair Programming? El Pair Programming puede mejorar dramáticamente la mantenibilidad del código y reducir la cantidad de bugs. Sin embargo, puede llevar al límite y a veces parece tomar un poco más de tiempo (si priorizamos cantidad sobre calidad). En lugar de obligar a los miembros del equipo, da el ejemplo y sugiere trabajar en parejas ciertos días de la semana. Algunos miembros del equipo pronto preferirán esta forma de trabajar.
Checklist del Scrum Master para el desarrollo organizacional
1.) ¿Hay suficiente coordinación entre los distintos equipos? Un Scrum of Scrums es la única forma de lograrlo. Adicionalmente, puedes enviar representantes de tu equipo a los Daily Standup Meetings de otros equipos.
2.) ¿La coordinación dentro del equipo la realizan realmente – como se recomienda – quienes ejecutan el trabajo diariamente?
3.) ¿Se reúnen los diferentes Scrum Masters para trabajar en la lista de impedimentos organizacionales?
4.) ¿Se comunican los impedimentos al director de desarrollo cuando es apropiado? ¿Se puede medir el coste en términos monetarios o en tiempo de lanzamiento perdido, calidad perdida u oportunidades perdidas para el cliente?
5.) ¿Es tu organización una de las pocas cuyas oportunidades de carrera son compatibles con los objetivos colectivos de los equipos? No es el caso si existen incentivos que lleven a programar o trabajar en la arquitectura a expensas de las pruebas, la automatización de pruebas o la documentación de usuario.
6.) ¿Ayudas a crear una organización de aprendizaje?
7.) ¿Es tu organización conocida en la prensa especializada o en otras fuentes independientes como un lugar de trabajo atractivo o líder del mercado?
El miedo es tu amigo
En cuanto te des cuenta de todo lo que puedes hacer para marcar la diferencia, quizás sientas miedo. Pero eso es solo una señal de que vas por el camino correcto.
Este texto proviene del blog de la Scrum Alliance y fue traducido por nosotros al alemán.
