El tema de un Scrum Master a tiempo parcial es una de las inquietudes que más he encontrado al hacer consultorías, en los cursos de certificación que he dictado o en mis trabajos previos como Scrum Master.
¿Debería ser el pusto de Scrum Master de jornada completa o puede ser un role compartido?
Parte de la respuesta lo abordé en las entradas anteriores; detrás de esto está la suposición implícita que el Scrum Master no es un role de jornada completa. La mayor parte de las conjeturas se basan en la idea que el fusionar dos roles puede hacer un ahorro sustancial de dinero y así incluir las responsabilidades de ambos en una sola persona.
Es casi inmediato el comprender que un un miembro del equipo de programación es de jornada completa porque sin el no habría software posible, se le puede ver escribiendo código, se lo ve sentado enfrente del computador y ello implica su necesidad. El Propietario del producto es otro ejemplo, se pasa todo el día planificando las características del producto y trabajando en el mapa de ruta, negociando con las partes interesadas, priorizando, descomponiendo historias de usuario, etc. Sin embargo, es difícil para las personas que recién comienzan con Scrum el imaginar un Scrum Master como de tiempo completo.
He trabajado como Scrum Master por mucho tiempo en diferentes empresas y paises, desde pequeñas hasta muy grandes.Es un trabajo muy dificil ya que requiere de muchas habilidades y energía y debo decir que la mayor parte de mis días comenzaban temprano en la mañana, transcurrían muy frenéticamente y finalizaban siempre con mucho trabajo.
Por otra parte, las empresas que recién comienzan también piensan que es el grupo quien dicta lo que se hará y nunca el Scrum Master. Esto en realidad no es tan así, ya que este último puede indicar que se necesita mejorar un área, por lo que se debería probar una técnica por 2 semanas. Luego el equipo tendría que evaluar si funciona, y de ser así incluirlo.
En mi criterio, quienes se preguntan que hace un Scrum Master de tiempo completo no conocen lo que este hace en realidad. Raramente en las empresas que trabajé como Scrum Master tendría tiempo para «compartirme» entre dos grupos. Estoy de acuerdo con Bernd Schiffer sobre las tareas que debe hacer un Scrum Master y he complementado ellas con otras que han ido surgiendo con el paso de los años:
1. Facilitar cualquier reunión del Equipo; incluyendo preparar, moderar y procesar posteriormente los resultados de la reunión
2. Organizar y moderar las retrospectivas.
3. Asesoramiento individualizado a los miembros del equipo
4. Mediar en conflictos que surjan durante el desarrollo del rpoducto
5. Ayudar al equipo a tomar decisiones
6. Fomentar la auto-organización del equipo
7. Mediar en el conflicto general entre los objetivos del Equipo y los objetivos del dueño del producto (alta
calidad técnica vs. más características).
8. Continuamente aprender, leer y reflexionar sobre cualquier cosa con respecto a Agile (por ejemplo, visitar grupos de usuarios, asistir a conferencias, leer libros, escribir blogs, etc)
9. Dar soporte a los miembros del equopo y a la organización con respecto a todo lo que es Agile.
10. Ayudar al Equipo a crear radiadores visuales.
11. Dar retroalimentación al equipo.
12. Fomentar el uso de prácitcas de ingeniería dentro del equipo de desarrollo
13. Desafiar al equipo con innovaciones de gestión Agile.
14. Intercambiar constantemente puntos de vista, técnicas y experiencias con otros Scrum Master de la empresa a través de comunidadades de práctica.
15. Ayudar al Equipo y Propietario del producto a escribir y separar las historias de usuario
16. Ayudar a las partes interesadas y dueño del producto a comprender como escribir y separar las historias de usuario.
17. Ayudar a las partes interesadas y propietario del producto a crear una visión del producto.
18. Ayudar al propietario del producto a comprender como organizar los elementos de la pila y enseñarle técnicas.
19. Ayudar al Equipo de desarrollo, dueño de producto, partes interesadas a con la entrega de la planificación
20. Estar familiarizado con el producto y el trabajo del equipo
21. Reunir a personas que deberían hablar entre sí pero no lo hacen
22. Estar en contacto con las partes interesadas regularmente
23. Ayudar al Equipo de desarrollo y al propietario del producto para que proporcionen información significativa, apropiada y puntual a la dirección.
24. Ayudar a promover la comunidad de Scrum y Agile dentro de la organización
25. Organizar eventos de intercambio para los miembros del equipo, propietario del producto, partes interesadas de la organización
26. Facilitar e implementar la diseminación de conocimiento en el grupo, por ejemplo organizando las sesiones «Brown Bag»
27. Compartir perspectivas por toda la compañía
28. Ser la persona de contacto para todo el mundo, tanto sea el Equipo de desarrollo, partes interesadas, etc sobre Scrum/Agile
29. Dar oportunidades de aprendizaje a las personas en la organización a través de charlas, talleres de trabajo, u otros foros y dejarles que aprendan conceptos importantes sobre Agile.
30. Ayudar al equipo a identificar y deshacerse de los impedimentos
31. Sugerir nuevas métricas para que el equipo de desarrollo las use como catalizadores para el cambio.
32. Reflejar los valores de Agile y Scrum al equipo.
33. Recordar al Equipo de desarrollo sus disposiciones, normas y políticas
34. Ayudar continuamente al equipo de desarrollo a mejorar sus procesos
35. Plantear cuestiones a las personas de desarrollo a través de la observación desde una visión de fuera del Equipo.
36. Realizar preguntas abiertas [poderosas].
37. Comprobar todos los modelos que el Equipo utilizasa (Sprint Backlog, métricas, etc. y demostrarles las diferencias entre el modelo y la realidad.
38. Ayudar al Equipo a centrar la atención actuando como un amortiguador entre las distracciones exteriores y el equipo.
39. Ayudar al equipo a mantener las herramientas de Scrum (Pizarra de tareas, Tablón de acciones, gráficos, pils, etc.)
40. Ayudar al equipo y al propietario del prodcuto a establecer una definición de hecho apropiada.
41. Preveer el futuro, como quiere el equipo trabajar la próxima semana, el próximo mes, año…
42. Construir y articular un objetivo o meta común para el equipo.
43. Ayudar al equipo a construir un grupo de valores que lo identifiquen.
44. Colaborar con futuros aspirantes de Scrum Master.
45. Ayudar al Equipo a mejorar sus habilidades sociales, especialmente con respecto a conversaciones constructivas.
46. Establecer las actitudes positivas y re-afirmarlas
Puede que me haya olvidado de alguna, pero a grandes rasgos están la mayoría.
Nuevamente la pregunta hay que tener en mente que se considera un equipo de alto rendimiento y cual es el principal motivo para eliminar este role.
Realmente te recomiendo como buen punto de partida interiorizarte con los Sistemas de pensamiento y Sistemas complejos para así poder entender la repercusión de un cambio de este tipo.
Esto finaliza la entrega de 4 partes de porqué un Scrum Master no debe ser de tiempo parcial o compartido con otro role de Scrum.
(artículo que corresponde a mi opinión en tema del grupo Linkedin de Agile Spain sobre Scrum Master parcial/compartido)
