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.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

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?

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

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.

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

¿Tiene mi equipo Scrum los conocimientos necesarios para construir mi Producto?

Scrum propone que nuestros equipos tengan todos los conocimientos para generar productos que cubran nuestras necesidades. Te traigo hoy una herramienta sencilla para averiguar si tus equipos Scrum son realmente multidisciplinares.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

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

ACEPTAR
Aviso de cookies