Este listado es un recopilatorio de ideas sobre objetivos que, desde mi punto de vista, debe intentar cumplir un Scrum Master. Es en principio un listado personal que no pretende ser definitivo ni absoluto.

Hace un tiempo que venía construyendo borradores y, en este punto, partiendo de la base de que en definitiva no lo considero ‘terminado’ (si es que alguna vez lo estará, e inicialmente no era mi intención publicarlo), creo que me vendría bien someterlo a juicio de quien pueda interesarse, cuestionarlo, y quizás, encontrarle valor. Inicialmente esta ampliamente basado en scrummasterchecklist.org.

Está orientado a ser práctico, de tal manera que un item reduzca el espectro de posibilidades de acción a un objetivo un poco más concreto, sin limitar la creatividad, personalidad y adaptación al contexto de cada Scrum Master.

Si bien el nombre es un error, y la definición básica tiene un foco absurdamente reducido, considero que el Scrum Master tiene una responsabilidad, una obligación con sí mismo y la organización en la que participa: ser un auténtico motor de cambio.

En ocasiones percibo que se intenta limitar el campo de acción del Scrum Master de una manera que considero anti-natural a su esencia misma, muchas veces producto de la tradicional visión jerárquica heredada que existe en muchas organizaciones. Si bien creo que la jerarquía puede ser incómoda, no es una limitante para que el Scrum Master recorra cada pasillo de la organización buscando estas grandes transformaciones que la misma necesita, sin perder, por supuesto, el foco en el equipo en que participa. El equipo es sin duda el que termina generando todos los items de este listado y motivando grandes cambios para la organización.

Product Owner

Product Backlog

• Prioridad->valor: Revisa frecuentemente si el Product Backlog se encuentra priorizado consistentemente con lo que transmite el Product Owner que es lo que representa mayor valor de negocio, ayudándolo a anticipar dependencias.
• Necesidades: Revisa si están capturadas las necesidades de todos los interesados en el producto y si esta incluido el valor que otorgaría satisfacerlas.
• Próximas PBIs preparadas: Verifica si todas los PBIs de la parte superior del backlog están correctamente preparados para el Siguiente Sprint (Definition Of Ready) y que no hay ambigüedades en la definición.
• INVEST: Indaga si los PBIs de la parte superior del backlog cumplen la definición de INVEST (Independiente, Negociable, de Valor, eStimable, pequeño, y Testeable).
• Tamaño adecuado: Revisa si es de un tamaño manejable, con PBIs con alto nivel de detalle y claridad cumpliendo INVEST en la parte superior, y gradualmente menor nivel hacia la parte inferior.
• Radiador: Asegúrate de que el Product Backlog sea un radiador información, claramente visible y accesible para todos los interesados (No un ‘refrigerador’ con poco acceso, cambio y visibilidad).
• Herramienta adecuada: Verifica si el PO sabe cómo usar la herramienta de gestión del backlog y la considera adecuada.
• Valor de negocio: Verifica si hay claridad sobre qué es valor de negocio y lo que lo genera, identificándose en cada PBI.
• Liderazgo de refinamiento: Empodera al PO del refinamiento para que sea liderado por el, preparando el backlog de cara a los próximos sprints, priorizando el siguiente, proponiendo, escuchando al equipo y actualizando los PBIs.
• Liderazgo de planning: Empodera al PO de la planning para que sea liderado por el, ajustando las prioridades y actualizando los PBIs con celeridad en conjunto con el equipo, buscando identificar los adecuados para el compromiso del sprint.
• Conciencia técnica: Verifica si es consciente el dueño del producto sobre lo que es la deuda técnica, su importancia, impacto y cómo evitarla. Entiende que la misma se puede ver reflejada en los compromisos del sprint y las formas evitarla pueden impactar la construcción de PBIs.
• Tiempo: Asegúrate de que cuenta con el tiempo disponible suficiente para mantener los PBIs adecuadamente.

Releases

• Actualización constante: Apoya para que el plan de releases sea actualizado frecuentemente, procurando liberaciones en producción de los resultados de cada sprint si otorgan valor y se encuentran correctamente preparados.
• Radiador: Verifica que todo el equipo conoce y colabora con el plan de releases, conociendólo con claridad y apoyando su definición.

Colaboración con equipo

• Radiadores de equipo: Comprueba con el P.O. si los radiadores de información del equipo son claros y transmiten realmente lo que pretenden, e incentiva su integración con el equipo para proponer mejoras e incluso interactuar también con ellos.
• Generación de confianza: Invita constantemente al Product Owner a recordar al equipo que esta disponible para ell@s, a interactuar proactivamente generando y fortaleciendo lazos de confianza.
• Tiempo: Asegúrate de que cuenta con el tiempo disponible suficiente para colaborar con el equipo adecuadamente.

Agilidad

• Asegúrate de que el Product Owner entiende la agilidad y acude al Scrum Master para buscar claridad sobre cualquier duda.

Equipo de desarrollo

Equipo

• Identidad: Trabaja para que cada miembro del equipo posea una indudable identidad con el mismo, que estén orgullosos de el y se sientan a gusto manifestándolo. No lo fuerces.
  
• Visión: Construye con ell@s una visión de equipo con un propósito que l@s motive.
• Alineación y éxito: Ayúdalos a estar alineados y a celebrar el éxito de los otros como suyo propio.
• Tiempo y valoración de la mejora: Incentiva en el equipo la mejora continua para que le dediquen tiempo y le presten tanta importancia como a las entregas de producto.
• Tamaño adecuado: Tiene entre 3 y 9 personas con una mezcla de las habilidades necesarias para construir un incremento del producto potencialmente entregable.
• Metas alcanzables: Las metas son alcanzables, alineadas apropiadamente con el conjunto de habilidades y capacidades de los miembros del equipo.
• Concentración y enfoque: Asegúrate de que tienen un alto grado de concentración limitado a un campo de atención concreto, y apóyalos cuando algo intente afectar su foco.
• Voluntarios / colaborativos: Incentívalos para que se ofrezcan como voluntarios para las tareas y para colaborar con las tareas de los demás, sin importar su naturaleza. Intenta inculcar el entusiasmo por aportar al equipo.
  
• Responsables como equipo: Trabaja para que, voluntariamente, sean colectivamente responsables de todos los aspectos del trabajo acordado (desarrollo, pruebas, documentación del usuario, documentación técnica, etc).
• T-Shaped: Aunque existan especialidades, verifica que todos están dispuestos a apoyar y aprender en las tareas que no son su especialidad.
• Adaptación al cambio: Asegúrate de que las expectativas y las reglas son discernibles.
• Multidisciplinar: Verifica si el equipo puede construir software funcional y potencialmente pasable a producción sin dependencias de otras áreas, incluyendo la arquitectura.
• Dailys: Asegúrate de que participan en las dailys en forma dedicada para sincronizarse con todo el equipo e identificar oportunidades de colaboración. Que entiendan que no es una reunión de seguimiento, velen por el cumplimiento de objetivo y valoren estrategias de apoyo (como la realización de pie, el token, entre otras). Que incluyan al Product Owner si lo consideran necesario, o permiten y entienden su participación pasiva.
• Independencia del SM: Explícales porqué no deben poseer ninguna dependencia del Scrum Master, funcionando sin él, sin embargo, enséñales tu trabajo para que valoren, entiendan y favorezcan la importancia del rol en el equipo.
• Persistencia: Apoya al equipo para que no se rindan ante la presión ni la angustia, las dificultades técnicas, bugs desagradables o un sprint complicado.
• Conversaciones de equipo: Trabaja en que el equipo disfrute reunirse para trabajar juntos y se interese en participar en las conversaciones/»ceremonias» de equipo.

Radiadores

• Actualizados y organizados: Empoderalos de los radiadores, como el tablero y demás, para que los mantengan actualizados y lo usen para organizar el trabajo y hacerlo visible, claro y transparente, comunicando el estado del proyecto y apoyando su día a día.
• Utilidad: Ajusta y motiva al equipo a que ajuste el tablero y demás radiadores de información, para que se sientan a gusto con su utilidad y contenido.
• Protección de mal uso: Verifica que están estos artefactos adecuadamente protegidos de personas que quieran realizar control y microgestión.

Software funcional

• Orgullo: Indaga si el equipo entrega software del que se sienten orgullosos.
• Potencialmente entregable: Trabaja para que el equipo entregue software listo para producción en cada sprint.

Motivación y bienestar

• Estado de flow: Identifica en los miembros del equipo que aspectos de su trabajo pueden ocasionar la perdida ocasional del sentimiento de auto-conciencia (la fusión de la acción y la conciencia) e intenta generar espacios propicios para que se genere en algunos momentos del sprint. Si ocurre excesivamente, trata de introducir novedad para que no caigan en ensimismamiento.
• Motivación intrínseca: Apoya la construcción de escenarios en que la actividad sea intrínsecamente gratificante.
• Moral alta: Intenta generar entusiasmo, sentido o propósito, desafío y orgullo por el aporte que cada uno hace al equipo. Procura que cada uno sienta energía, fuerza, capacidad de recuperación rápida y proyección con el equipo. La moral refleja la sostenibilidad.
  

Mejora continua

• Feedback directo e inmediato: Apoya la generación de momentos para que los éxitos, los fracasos, las potencialidades y los problemas, en el curso de la actividad sean evidentes o comunicados en el momento en que son identificados por algún miembro del equipo, para que el comportamiento se pueda ajustar rápidamente según sea necesario.
• Desafío: Estimula la toma de compromisos y distribución del trabajo de forma que haya equilibrio entre el nivel de habilidad necesaria y el desafío que supone conseguir los logros (cada actividad a realizar no es ni demasiado fácil ni demasiado difícil).
• Crítica, propuestas y compromisos: Genera espíritu de mejora a través de crítica, autocrítica, propuestas de cambios y compromisos palpables a corto plazo.
• Retrospectivas diversas: Plantea variedad de formatos y/o lugares para las conversaciones de Retrospectiva del Sprint, de acuerdo a la realidad del equipo, e invita a miembros del equipo a organizar retrospectivas.
• Experimentos: Estimula para que el equipo genere por sí mismo cambios frecuentes a través de experimentos concretos de mejora.
• Soluciones: Verifica si identifican posibles soluciones a cada problema o impedimento y las proponen abiertamente, impulsando su ejecución si es aceptada.
• Agilidad y SM: Aprovecha la experiencia, genera confianza y aprende continuamente según las necesidades del equipo para dar asesoría o referencias para mejorar en términos de agilidad.

Calidad

• Deuda técnica: Se ha hecho explícita la deuda técnica en los artefactos de organización del trabajo del Sprint, incluidos como radiadores de información.
• Orgullo: El equipo se siente orgulloso de la calidad del código que entregan en cada sprint.
• D.O.D.: La definición de done es revisada por cada miembro del equipo para asegurar que una historia esta terminada.
• Pruebas automatizadas: Se realizan pruebas funcionales, de regresión, unitarias y de sistema automatizadas.
• Integración continua: Se tiene un servidor de integración continua que hace saltar una alarma cuando se provoca una falla de regresión, encargándose de ejecutar todas las pruebas en poco tiempo.
• Radiadores de calidad: Cualquiera, sea del equipo o no, puede detectar cuando se ha causado una falla de regresión.
• Diseño emergente y refactorización: Realizan diseño y refactorización constante.
• D.O.D. con pruebas y refactoring: La definición de «hecho» incluye cobertura completa de pruebas automatizadas y refactorización.
• Pair programming: El equipo hace pair programming una parte significativa del tiempo.

Scrum Master

• Mindset: Debe reconocer en la agilidad una forma de ser (primero) y hacer (segundo) las cosas, e identificarse con ellas. La agilidad puede llegar a concebirse de forma única para cada persona, es importante identificar las bases y posterior a ellas respetar la diferencia, más aún cuando está fundada en conocimiento y experiencia.
• Humildad: La humildad es característica fundamental.
• Paciencia: Los cambios son difíciles, cada persona y cada equipo son un mundo. La paciencia es fundamental. No se debe confundir con pasividad.
• Escuchar: Sabe escuchar y lo mejora adecuandolo a cada persona.
• Ejemplo: Da ejemplo con su comportamiento.
• Scrum y agilidad: Debe conocer, en la teoría y en la práctica, todo lo posible de lo que implica la agilidad y aprender constantemente.
• Consentimiento: El equipo está dispuesto a recibir coaching, trainning y sugerencias.
• Observar: Reconocer el equipo. Quizás, solo quizás, fase de Tuckman: forming, storming, norming, performing. Que no se confunda, no se debe ser solo un observador del equipo (o no siempre).
• Scrum Master tiempo completo: Un Scrum Master con un solo equipo. Siempre hay acciones de cambio y mejora (sin tiempos muertos).
• Comunicación No Violenta: Aprende y perfecciona estrategias y prácticas de Comunicación No Violenta.
• Feedback constante: se da y se recibe feedback constante bajo las formas más adecuadas según la persona y el momento.
• Coaching: El Scrum Master realiza Coach 1 a 1, de equipo y a la organización. Aprende constantemente cómo mejorar su Coaching.
• Con el equipo: El Scrum Master está con todo el equipo en el mismo espacio de trabajo.
• Día persona: Ocasionalmente dedica una parte significativa de un día a algún miembro del equipo para apoyar mejor su proceso, principalmente cuando tiene alguna dificultad latente.
• Comunicación de ideas: mejora constantemente la forma en la que transmite las ideas al equipo.
• Timebox: Busca la asignación de un tiempo adecuado a cada conversación/“ceremonia” y su cumplimiento, procurando a ayudar a concluirla con algún resultado de valor.
• Panorama global: Procura mantener un panorama global del proyecto, el producto y la organización para mejorar su labor.
• SMs y otros equipos: Visita y aprende de otros equipos y Scrum Masters con regularidad, dando y recibiendo feedback con estos últimos.
• Conformación de equipos: Procura estar desde la conformación de un equipo.
• Recepción de Coaching: Recibe coaching.

Equipo Scrum: Equipo, PO, SM

• Conversación creativa: Estimula y apoya las conversaciones creativas que promueven el conocimiento, el descubrimiento, el asombro y la construcción de sueños o de ideales.
• El ritmo adecuado: Procura estimular al equipo para encontrar el ritmo adecuado para cada actividad que realizan, evitando la presión tradicional que pretende acelerar exesivamente sus actividades o el desinterés que pretende reducir al máximo el tiempo de trabajo en las tareas.
• Objetivo del sprint: Está claramente definido el objetivo o foco del sprint.
• Mejora continua: Se ha mejorado la forma de trabajar en cada sprint.
• Empoderamiento del proceso: El equipo se empodera por completo del proceso, no solamente del desarrollo, buscando asesoría del Scrum Master.
• Timebox: Los horarios definidos son respetados por todos y se dinamizan las reuniones para iniciar y terminar en los tiempos acordados.
• Métricas con valor: Las métricas y gráficas (burndown, velocity, etc) generan valor al equipo y/o al cliente.
• Review preparada: Si bien es una conversación/”ceremonia” poco formal, orientada a presentar a los stakeholders el producto potencialmente enviable a producción, y recibir su feedback para considerar las adiciones, cambios y mejoras, debe tener preparación por parte de todo el equipo Scrum de tal forma que sea clara y provechosa.

Organización y DevOps

• Comunicación y colaboración entre equipos: Existe una comunicación fluida, directa y adecuada entre distintos equipos que colaboran en la construcción de un mismo producto.
• Área IT y equipos: El área de IT/infraestructura y los equipos colaboran mutuamente reconociendo el trabajo del otro y colaborando en la consecución de objetivos comunes.
• Impedimentos organizacionales: Los impedimentos organizacionales son visibles y hay personas responsables de gestionarlos.
• Aprendizaje: Hay aprendizaje y mejora constante en la organización.
• Cultura de mejora continua: No se busca definir un proceso estable y estricto, sino más bien, desarrollar una cultura de mejora continua en todas las áreas de la organización.
• Interacciones valiosas: Todas las interacciones entre personas de la organización y cada equipo aportan valor (a uno, al otro, o a ambos).
• SM y transformación ágil: Se busca apoyo de cada Scrum Master para la planificación y ejecución de la transformación ágil de la organización.
• SMs e impedimentos organizacionales: Se reúnen entre sí los Scrum Masters, trabajando para complementar, resolver y/o ayudar a la resolución de la lista de impedimentos de la organización.
• Reconocimiento real: La organización ha sido reconocida por la prensa, fuentes independientes y la comunidad en general como uno de los mejores lugares para trabajar y/o líder en su industria.
• Realización profesional: La organización está comprometida con la auto-realización profesional de los miembros de sus equipos.

Agradezco de antemano sus opiniones.