Scrum master a tiempo completo: 42 Tareas

Uno de los artículos que más referencio en mi formación en Scrum cuando hablo de las labores del Scrum Master es: 42-tasks-for-a-scrum-masters-job. Por alguna razón, todo el mundo parece entender que el Product Owner es un trabajo a tiempo completo, o ser miembro de un equipo también, pero que probablemente el rol del Scrum Master puede ser realizado a media jornada o incluso menos.
El scrum master también tiene mucho trabajo en equipos medianos o grandes, o nuevos. Muchos de liderazgo. Y es preferible que se centre en sus tares como scrum master, compartiendo su trabajo entre dos equipos por ejemplo, que trabajar también con la gorra compartida de miembro del equipo. ¿Por qué? Por que las labores que tenderá hacer son las de desarrollador antes que las de scrum master.

He querido traducir este artículo, para que quede en castellano, con permiso de Bernd Schiffer, para que quede constancia, y pueda referenciarlo en nuestro idioma :)

Artículo original: 42 Tasks for a Scrum Master’s Job

Las siguientes preguntas aparecen a menudo cuando realizo formaciones o consultorías en Scrum:

¿Por qué los roles de Scrum Master y Project Manager deberían ser llevados por personas diferentes? (Quora)
¿Será el Scrum Master una ocupación al 100% o puede un programador ocuparse de ello si tiene mucha experiencia en planificación ágil? (Quora) 

Tras estas preguntas está la suposición de que el Scrum Master no es un rol a tiempo completo. Quien hace esas preguntas conjeturan con la posibilidad de ahorrar dinero juntando dos roles en una sola persona.

Las preguntas son realizadas por novatos como Scrum Masters, por product owners, por miembros del equipo, por managers, por stakeholders de cualquier tipo. De los tres roles en Scrum, todos parecen inferir inmediatamente que ser miembro del equipo es un trabajo a tiempo completo -por que desarrollan software el día completo - y que ser un product owner es también a tiempo completo - por que desarrolla el producto todo el día-, pero parece difícil de imaginar cual es el trabajo de un Scrum Master pueda ser y el por qué diablos sería un trabajo a tiempo completo, también.

¿Quizás esos que preguntan no sepan que es lo que un scrum master hace todo el día?

Aquí presento una lista de 42 cosas que diría que son parte del trabajo de un scrum master:

Reuniones

- Facilitar reuniones para el equipo. Esto incluye:

   - Preparar

   - Moderar

   - Postprocesar

 - Realizar retrospectivas, que son especiales, por consiguiente las cuento separádamente.

Dinámicas de equipo

 - Realizar coaching a los miembros del equipo (p. ej. coaching 1a1)

 - Mediar en los conflictos

 - Ayudar al equipo en la toma de decisiones

 - Fomentar la auto-organización del equipo

 - Mediar en el conflicto de objetivos entre el equipo de desarrollo (alta calidad técnica) y el product owner (más funcionalidad)

Aprendizaje

 - Continuar aprendiendo todo lo relativo a Agile (p. ej. visitar grupos de comunidades, atender a conferencias, leer libros, escribir blogs,…)

 - Asesorar a los miembros del equipo en todo lo relacionado con Agile.

 - Ayudar al equipo a crear radiadores de información.

 - Dar feedback al equipo.

 - Fomentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (esto es un enorme trabajo para invertir el tiempo de un Scrum Master, incluyendo por ejemplo, publicación/releases automáticas, entrega continua, TDD, y muchos más).

 - Desafiar al equipo con nuevas ideas sobre Agile Management (p. ej. FedEx -Days).

 - Colaborar constantemente con otros Scrum Master en la organización (p. ej. a través de la comunidad de práctica).

 - Bajar al Gemba.

Producto

 - Ayudar a escribir o dividir historias de usuario.

 - Ayudar a escribir o adaptar la visión del producto.

 - Ayudar a ordenar los elementos de la pila de producto.

 - Ayudar con la planificación del sprint.

 - Estar familiarizado con el trabajo del equipo (p. ej. el producto)

[Sobre producto hemos escrito Desarrollo de Producto y facilitación]

Visión general

 - Juntar a la gente que debería hablarse entre ellos.

 - Estar en contacto con los stakeholders regularmente.

 - Ayudar al equipo a informar a management.

 - Ayudar a fortalecer la comunidad ágil dentro de la organización

 - Organizar eventos de intercambio como Open Spaces o World Cafes para el equipo, stakeholders y el resto de la organización

 - Compartir ideas y análisis en la compañía (micro-blogging, blogging, conferencias internas,…)

 - Ser la persona de contacto para todos en el equipo y los stakeholders en todo lo concerniente a Agile. 

 - Dar oportunidades de aprendizaje a la gente en la organización (p.ej. charlas o talleres) y permitirles aprender conceptos Agile importantes como p.ej. la deuda técnica.

Cambio

 - Ayudar al equipo a eliminar impedimentos.

 - Sugerir nuevas métricas para el equipo como catalizadores del cambio

Espejo

 - Reflejar los valores ágiles y de scrum al equipo.

 - Recordar al equipo sus acuerdos (p.ej. políticas)

 - Ayudar al equipo a mejorar constantemente sus procesos.

 - Reflejar los problemas al equipo a través de la observación desde fuera.

 - Hacer preguntas abiertas.

 - Comprobar los modelos que usa el equipo (p.ej. sprint backlogs, métricas, etc.) y mostrarles las diferencias entre el modelo y el mundo real.

Varios

 - Ayudar al equipo a mantener el foco (p.ej. actuando como un buffer entre las distracciones externas y el equipo)

 - Ayudar al equipo a mantener sus herramientas scrum (paneles, pilas de acciones, gráficas, backlogs,…)

 - Ayudar al equip y el product owner para encontrar los adecuados:

    - Definición de terminado (DoD).

    - Definición de preparado (DoR).

¿Has hecho o considerado todo lo mencionado anteriormente? Tomate un respiro, ¡debes estar agotado!

     Creemos que el scrum master es un rol a tiempo completo para una persona en un equipo Scrum. Scrum Master Manifesto.

¿Interesado en mentoring de Scrum Master? 
Contacta -TAYARI-

Agile Fluency Model en castellano

He publicado el modelo de fluidez ágil en castellano.



Este modelo desarrollado por James Shore y Diana Larsen proporciona una interesante perspectiva sobre el camino al agilismo por los equipos.

Modelo de fluidez ágil.

CAS2017: Conferencias Agile-Spain

La CAS2017 ha sucedido hace un par de días, y empiezo a leer las primeras impresiones, felicitaciones, quejas, enhorabuenas y protestas...

Mi visión sobre la CAS2017

 ¿Qué ha sucedido este año? Desde mi punto de vista personal, no puedo dar muchos detalles del contenido. ¡He visto muy pocas charlas! :) La CAS tiene cada vez para mi más de punto de encuentro que de conferencia dónde aprender. Puede haber temas interesantes, pero la verdad es que no voy por el aprendizaje. Además tiene ese puntito de satisfacción de ver cómo la comunidad ha conseguido poner en marcha semejante evento, tras verla nacer hace 8 años en un bar de Madrid.



 Este año fui seleccionado para dar un taller sobre Liderazgo para la transformación. Recogí buen feedback sobre la sesión, y sobre todo, me llevo algunas preguntas muy interesantes que me hicieron reflexionar sobre el contenido. Ahora estoy preparando un taller de dos días sobre liderazgo, y es impresionante cómo cuando impartes un taller, aprendes tanto o más que los asistentes si estás abierto a escuchar.


Sobre la conferencia de este año:

• ME GUSTÓ:
• Traer ponentes/keynotes de fuera del mundo Agile.
• El espacio: las salas estaban cerca y eran mayoritariamente cómodas. No hubo atascos.
• El control de tiempos de las charlas. La puntualidad era buena.
• Como siempre Autentia, grabando todas las charlas, estoy deseando ver alguna de ellas.
• El concepto tras la idea de "las chapas", para controlar el acceso a los talleres.
• La keynote final de Neil Killick donde después de 2 días de procesos, herramientas, ideas,... nos volvió a centrar en qué es realmente Agile.
• Las cajas para recoger el feedback, ¡genial! Sencillo, en el momento, y rápido.

• PARA MEJORAR en CAS2018:
• La agenda debe estar definida con más tiempo de antelación. Además, más claridad en la selección de las charlas, con feedback a los ponentes, más feedback de calidad de las mismas, mayor visibilidad del proceso
• Añadir track técnico. Más contenido para las bases del agilismo. ¿quizás otros formatos de talleres con esta orientación?
• Añadir dos tracks en inglés, mayor internacionalización.
• Se debe dar más visibilidad a patrocinadores pequeños/medianos.
• Hay que dar contexto a quién viene de fuera del mundo Agile para una keynote. La keynote de Ramón Cabezas parecía un speech de venta con cupón de descuento.
• Las salas para los talleres, al menos donde me tocó a mi, deben estar mejor preparadas, más espaciosas, y cómodas.
• La comida. O sea,... el queso ;)
• Las chapas era buena idea, y debía haber sido informada antes, y evitado también la acaparación de múltiples talleres de los primeros que llegaban.

Como siempre, un aplauso especial para los voluntarios. Claro que nunca hacen una conferencia perfecta a los ojos de todos. Pero la HACEN. Gracias.

Mi visión sobre la CAS (en general)

 El jueves por la tarde, tras el día de conferencia, tuvimos la enésima discusión sobre lo que queremos que sea la CAS. Como evento de referencia que se ha convertido en el panorama nacional (no hay más que ver dos empresas del IBEX-35 como patrocinadores), me pregunto si debemos dar un paso en su profesionalización. Para ello deberíamos ponernos de acuerdo como comunidad.

Me gustaría en realidad que la asociación representase a una mayoría de esa comunidad (Únete! https://agile-spain.org/asociate/), y tuviésemos claro el círculo de decisión sobre la CAS, podríamos dotar de mayor infraestructura a la organización, y permitir que los voluntarios se centrasen en el contenido.

 Mientras tanto, la dinámica de voluntarios ha funcionado, y espero que lo siga haciendo. :) Gracias de nuevo a todos.

Como siempre, la CAS es un momento de referencia para estar si te interesa el movimiento Agile. Las personas involucradas lo hacen especial. Cada año.

The "Groundhog day" retrospective

Some months ago I was feeling bored and tired of facilitating retrospectives. I have facilitated several hundreds of retrospectives, and sometimes you start again with a new team,  you repeat a lot of techniques and for sure continuously became a better facilitator (if deliberate practice, and feedback). Of course that every team is different, and the great part is the outcome, to feel their change. But at some point I was bored.

So now I tend to mix classical exercises with more tuned approaches to create new things for the teams. Please, give me your opinion about this: the groundhog day retrospective:

- First, you can do a classical check-in. For this first time I did Appreciation round, and review previous actions.

- Then, you draw a timeline for the past sprint. i asked the team to identify (with color codes) three things: 

 1) problems identified during the sprint

 2) improvements that they thought should have done

 3) Facts, things that happened, observations.

 When they finished the identification, I made the following statement: “Remember the film "Groundhog day"? So now, suppose we come back next day for the sprint planning, and suddenly, we discover we are in the same sprint. People live in the same day of the previous planning. We remember everything, but nothing is done. And the same thing will happen again. We have the same stories in the top of the backlog, and we are back in the same sprint planning than two weeks (length of the sprint) before. Look the sprint again, with new eyes, but with the same work to do”

 And now you ask three questions, and after each you repeat the statement.

 1) Individually, write ONE postit looking at the problems on the timeline. If you could solve one of these problems, now that you know it´s going to happen, what would you have done to solve it during the sprint?

 (let them work and put the ideas on the wall, and repeat the statement again, adding that the same sprint is back again! :)

 2) Individually, write ONE postit looking at the improvements on the timeline. If you could do one action to improve the sprint, what would you have done to improve the sprint?

 (let them work and put the ideas on the wall, and repeat the statement again, adding that the same sprint is back again! :)

 3) Individually, write ONE posit looking at the observations, evaluating their impact, What would you change on the team behaviour, on the team reactions to those things to perform better during the sprint?

 (great! finally we achieved an incredible sprint, we can move to the next one!)

 Take a look at the wall, let them search for patterns and groups. What´s there?

 Decide actions, observe if there is need for dot voting to prioritise, or some informal agreement emerge.

 And close the retrospective, get some feedback, and make sure that every action has a responsible.

Notes: (I only have used this retro once)

- I found that those questions and the power to change the past generated a good analysis and powerful debates.

- If the team is young, you probably have to explain the film first. Seriously. :D

- I think that if you use it for releases, longer times than iterations, probably the divergence will be too high. But, tell me if you try it, please!

Comments are welcome! 

Retrospectiva - Comunicación no Violenta (NVC)

Una de las herramientas que más he utilizado estos dos últimos años ha sido la Comunicación No Violenta (NVC, por sus siglas en inglés). De hecho, lo tengo como algo más que una herramienta, es una manera de relacionarte con el mundo.
Principalmente lo he usado como técnica de coaching y resolución de conflictos, pero sobre todo, como herramienta de auto-análisis y comprensión de mis interacciones con otras personas.

Así que me propuse utilizarlo para facilitar una retrospectiva, y encontré este artículo. Basándome en él, realicé la siguiente retrospectiva:

1. Check-in: Revisión de acciones anteriores. Y en este equipo: revisión del calendario Niko-Niko del equipo, y de la felicidad del mismo (mediante autopuntuación individual). 
2. Introducción a NVC: Explicación del fundamento de la comunicación no violenta, y explicación de las tarjetas que iban a tener que crear basado en el típico esquema de NVC: Observación - Sentimiento - Necesidad - Petición. Obviamente tanto para necesidades satisfechas como insatisfechas :)

3. Tarjetas: Individualmente, reflexión durante 15 minutos y escritura de las tarjetas, con una sentencia por tarjeta. Les pido que se enfoquen en las observaciones y sensaciones del último sprint. También les pido que escriban aquello que incluso no se atreverán a compartir después. Que lo escriban para su propia reflexión, y que se lo guarden para ellos mismos.
4. Trabajo en parejas:  Se trabaja en parejas, cada tarjeta de la siguiente manera: El autor la lee, y su compañero ESCUCHA, y pregunta con CURIOSIDAD para obtener más información sobre el contenido. Sugiero evitar consejos, juicios,... solo dejarse guiar por la curiosidad.
5. Compartir en equipo: Invito a cualquiera a compartir para todo el equipo sus reflexiones, si les apetece y se sienten cómodos. No feedback del resto, solo escucha de nuevo.
6. Revisión de peticiones, generación de acciones: Se vuelve a trabajar en parejas, y esta vez se analizan las peticiones finales de cada tarjeta. Se generan acciones en post-its para el equipo en base a esas peticiones personales. ¿cómo puede el equipo ayudar a satisfacer esas necesidades personas?
7. Agrupación y priorización: Compartimos las acciones en la pizarra, las agrupamos y las priorizamos. Asignamos responsables y las hacemos lo más concretas posibles. 
8. Check-out: Feedback sobre el ejercicio. Gracias al equipo.

Mis sensaciones como facilitador:

 - He realizado esta retrospectiva en hora y media. Creo que para un equipo de 10 personas es poco tiempo, hubiese necesitado más tiempo para la explicación inicial, e insistir con ejemplos de confusión de necesidades o "malas" observaciones. Si no conocen NVC, es realmente clave.

 - He observado útil repartir un pequeño inventario de necesidades y sentimientos.

 - Siempre he hecho invitaciones: a compartir, a expresarse, a contar sus sentimientos,..., dejando muy claro que cualquier persona era libre de pasar. No era un ejercicio obligatorio (obviamente, ¡como ninguna retro!).

 - Considero clave también el ofrecimiento a escribir, pero no compartir. Da la oportunidad de reflexión individual, incluso sin participación activa en la retro.

 - El feedback ha sido positivo. Las acciones que han salido, poderosas. Y sin embargo, mi sensación como facilitador ha sido que tenía perdido al grupo. Tengo que analizar más esto :)

Marco Scrum

Marco de Scrum

Curso de Scrum: Contactanos si estás interesado.

¡Aquí puedes ver el último video sobre Scrum en 9 minutos que hemos publicado!

CAS2013: Scrum y management, ni cerdos ni gallinas.

Scrum y management: ni cerdos ni gallinas. from Jose Ramón Díaz

Puedes ver el video: Joserra Díaz, scrum y management.

La metáfora de los cerdos y las gallinas es un drama. Y afortunádamente se dejó de usar en la guía de Scrum. Como chiste pase, pero diferenciar entre comprometida e involucrada en un proyecto, diferenciando su grado de compromiso es un poco anti-colaboración. Y con esos nombres... ¿algún cerdo en la sala? :\

Una de las gallinas es la capa de management, así que se supondría que no están comprometidas (sic) con los resultados de los proyectos (¿suena absurdo verdad?). 

• Henry Fayol – “Gestionar (management) es prever y planificar, organizar, mandar, coordinar y controlar”
• Control y gestión de los recursos de una organización para producir valor a los clientes
• Managers are the people who interrupt the ones working. Jason Fried (37 signals)
• Hay opiniones para todo, en general, Management es lo que hacen los managers. Así es más sencillo. Cada organización es un mundo

Ahora llegamos con una herramienta: Scrum. Que es el gran descubrimiento para el management. Lo dice Forbes nada menos, hace ya casi 3 años. ¡Ya les costó darse cuenta! ;) PERO, pero, hay algo que a veces no encaja… ¿qué tiene Scrum que no es una herramienta tan sencilla de utilizar en las organizaciones actuales?

Por alguna extraña razón la metáfora es entendida de otra manera. Y ni unos ni otros están del todo contentos con la nueva situación. El cambio de una mentalidad "command&control" a una verdadera autoorganización no es fácil, y no sabemos cómo usar esta nueva herramienta.

En general:

 - Mira la película completa, no microgestiones el equipo, sin tener en cuenta las influencias externas. El impacto en la organización completa.

 - Sal del edifico. Baja y comprueba in situ qué sucede, a la gente usando Scrum, a los equipos, a los usuarios, a los clientes,… ¡pasea por el gemba!

 - Cambia el foco: la gente sabe cómo definir procesos, planes y todo eso… eso es fácil. Cambia tu foco a las personas, mira si hay colaboración, comunicación, entendimiento,…

Así que si como manager quieres usar Scrum, ¿dónde te colocas?

- Si pasas a set product owner… o mejor no. NO lo hagas. Parece el camino más natural, pues controlas releases, planificaciones, hablas más con los usuarios, stakeholders, etc. Pero ser jefe de equipo, y product owner desequilibra la balanza PO <-> SM. Totalmente. Si no tienes tiempo para algo, será el equipo el que lo sufra. 

- Si eres un manager externo al equipo, y este cuenta con su PO y su SM, puedes tener la sensación de "y ahora, ¿qué hago?" Pero si la organización está arrancando con Scrum es fundamental su protección y ayuda al scrum master a que no se de cabezazos con el resto de la organización. Que el equipo no pierda de vista el propósito de lo que está haciendo. Ayúdales en eso.

- Si eres un manager de varios niveles superiores, pasea por el gemba, baja a ver qué sucede, atento a lo que suceda en los equipos scrum, las personas alrededor de los equipos en otras áreas de la organización, identifica a tu equipo de trabajo y trabajad para mejorar el sistema, y apoyar aquello bueno que emerja.

 - Si eres jefe de equipo, el paso lógico es ser scrum master. Recuerda, equipo = producto. Trabaja en el equipo. Cambia de chip, prueba la autoorganización, ayúdales… y dales espacio.

 En definitiva, una  organización que empieza a hacer Scrum requerirá que el management se centre en las personas y el sistema completo, y no luche contra la organización si no que colabore, haga amigos, y la transforme.

* Nota, hablo de Scrum como una herramientas… y en realidad NO lo es. Es mucho más, incluye valores, principios, cambio de mentalidad… ¡¡por eso es difícil!!

Visión personal de la CAS2013

La conferencia Agile-Spain 2013 ya ha sucedido.

Echando la vista atrás ya se han olvidado los ratos (largos) haciendo facturas, comprando billetes de avión, reservando hoteles, el esfuerzo de un equipazo de organización,… 

Ahora recordaré a la inspectora de la fundación tripartita y la casi-evacuación masiva del edificio donde tomaba lugar la conferencia (!), las risas del equipo de organización, la brillantez y calidez de los keynotes, el abrazo con Tobias Mayer, la cercanía de Koldo Saratxaga, la amistad de Ángel Medinilla, las numerosas gracias recibidas desde los asistentes, las sonrisas cómplices con los amigos que desde lejos te buscaban a ver si necesitábamos ayuda, las amistades que nacen y crecen en estas ocasiones, las cervezas con compañeros de viaje, y... más cosas ;)

Me dolerá de esta conferencia el tiempo robado a mi familia, el no habernos acordado de los vegetarianos para el catering, el no haber compartido más tiempo con viejos amigos, y el hecho de que no acabe la burocracia en el mismo momento que termina el evento :)

Y celebro haber ayudado a la comunidad, haber colaborado en el camino hacia la maestría de tanta gente, a que los asistentes disfrutasen de dos días alrededor de un tema que nos apasiona.

Así que debo agradecer esos ratos a todos y cada uno: Aitor, Iñaki, Abdul, Frank, Vicenç, Bea, Anaje, Gorka, Cristina, Joseba,… y a esos alumnos de la universidad, que lamentablemente me acabo de dar cuenta no sé ni sus nombres. GRACIAS.