Cómo empezar como Scrum Master en un equipo

Es tu primer día como Scrum Master. Después de haber estudiado mucho acerca de metodologías ágiles y Scrum (incluso puede que te hayas certificado) ha llegado el momento de llevarlo a la práctica. Pero, ¿por dónde empiezo? ¿Cómo definimos la duración de los sprints? ¿Cómo vamos a tratar la deuda técnica? ¿Cuántas incidencias resolvemos en cada sprint?

Tranquilo, aquí te dejamos algunas recomendaciones para empezar a desarrollar el rol en un nuevo equipo:

 

Dedica tiempo para ver cómo trabaja el equipo

Es normal que al enfrentarte a un nuevo reto, las ganas de empezar te hagan meterte “en harina” nada más llegar. Sin embargo, bajo nuestra experiencia es necesario darse un tiempo para conocer cómo trabaja el equipo. ¿Qué tecnologías utilizan? ¿Qué roles (formales o informales) hay dentro del equipo? ¿Qué conocimientos tienen acerca de las metodologías Ágiles? Si ya utilizan algún marco como Scrum, acompáñalos como observador para comprobar cómo se desenvuelven y descubrir qué potenciales oportunidades aparecen.

 

Conoce a los miembros del equipo

Tanto si el equipo tiene conocimientos de metodologías ágiles como si no, no está de más planificar una serie de sesiones one-to-one con todos los miembros del equipo para tener un primer contacto. No tiene por qué ser una reunión con un gran protocolo. Una invitación a un café puede ser un gran momento para una conversación distendida. Conocer cómo realiza su trabajo, su impresión sobre el funcionamiento del equipo y en qué podemos comenzar a ayudar al equipo ya es más que suficiente para 15-30 minutos de conversación.

 

Revisa el Product Backlog

Si el equipo tiene un Product Backlog, es el momento de ver en qué estado se encuentra. ¿Quién escribe los PBIs? ¿Utilizan algún formato para escribirlas? ¿Incluyen criterios de aceptación? Estudiando el nivel de salud del Product Backlog podemos empezar a intuir algunos problemas típicos que ocurren cuando, por ejemplo, los PBIs no cuentan con los criterios de aceptación o su descripción es reducida a modo de titular.

 

Revisa el panel de tareas

Otro punto interesante es el panel de tareas. ¿Se trata de un panel físico o virtual? ¿Cada cuánto se actualiza? ¿Hay alguna fila o columna que acumule gran cantidad de trabajos? ¿Tienen trabajos de testing o resolución de incidencias? Si no existe un panel debes encontrar cuál es el proceso que siguen para planificar y visualizar el trabajo en curso. En el caso en que tengan una aplicación, como Jira, además de consultar el panel puedes ver cómo han sido los sprints anteriores, nivel de cumplimiento, incidencias resueltas, trabajos que han estado asignados en varios sprints…

 

Busca en otros equipos

Si tienes la suerte de contar con otros equipos cercanos que ya hayan hecho su inclusión en las metodologías ágiles, es el momento de ir a contactar con ellos. Seguramente alguno de los problemas que se encontraron su Scrum Master o Product Owner al inicio y sus soluciones te ayuden.

 

Define un sistema de indicadores de seguimiento

Consensúa con el equipo qué indicadores podéis recoger en cada sprint para hacer un seguimiento de la evolución del equipo. No deberías necesitar más de 3 o 4 valores para empezar. Estos indicadores pueden ser de gran ayuda para enfocar las retrospectivas. Si necesitas ayuda sobre qué indicadores recoger, echa un vistazo al artículo que hemos publicado sobre nuestra experiencia en un cliente.

 

Como verás, extraer esta información nos puede llevar varias semanas. Según sea la disponibilidad, podríamos estar hablando entre dos y cuatro semanas de trabajo. Siempre en función de la realidad de la compañía y del equipo. Una vez hayas realizado todos estos descubrimientos tendrás mucho más claro qué necesita tu equipo para dar un salto de rendimiento. En estas ocasiones, la calma y la templanza son tus mejores aliados.

No te preocupes si no dispones de tiempo para observar al equipo o simplemente es un equipo que acaba de crearse y no hay suficiente información, según avancen los sprints podrás extraer toda esta información y modelarla adecuadamente.

Por último, no olvides que cada persona es diferente y lo que nos funcionó en anteriores equipos, puede no funcionar en otros. Dedicar tiempo a observar a las personas, sus relaciones y su forma de trabajar, nos permitirá ajustar la estrategia para acompañar en las mejores condiciones al equipo Scrum. Recuerda que acompañar implica que nos adaptemos a la realidad compleja del equipo y traccionemos con ellos, y no que les “obliguemos” a ir a donde nosotros queremos.

También te puede interesar.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

¿Quién debe priorizar el Product Backlog en Scrum?

Agile y Scrum nacen principalmente del mundo del Software, aunque en los últimos años se han llevado a otros ámbitos de las empresas. Scrum plantea al Product Owner como una única persona. La realidad de la empresa nos empuja a implementar algún tipo de escalado de Scrum, en el que aparecen, de una forma y otra, Product Owners de Product Owners. ¿Significa esto que se está haciendo una mala implementación de Scrum? ¿O nos estamos adaptando a las necesidades tal y como indica Agile? ¿Tiene que de verdad ser una única persona? ¿O hay otras posibilidades manteniendo la cultura Agile?

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Sube el nivel de los Scrum Master

Es importante cuidar el rol de Scrum Master ya que es el encargado de velar por la transformación del equipo y la organización.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies