Mi estrategia de OnBoarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

 

Haber pasado por esa situación en varias ocasiones me ha hecho ver que el enfoque que mejor me funciona es plantear este aterrizaje de un modo iterativo e incremental basado en la inspección, adaptación y transparencia, ¿os suena? ¡Usar Scrum para aplicar Scrum!

Podemos enfocar nuestro trabajo de Scrum Master como nuestro proyecto personal. Desde esta perspectiva vamos a definir un backlog, lo priorizaremos y planificaremos, y tras poner en marcha las primeras acciones haremos un ejercicio de retrospectiva, para de nuevo volver a iterar. ¡Comencemos!

 

ANTES DE NADA, ENTENDER CUAL ES LA SITUACIÓN DE PARTIDA

Inicialmente nuestro foco estará en observar qué es lo que ocurre y lo que no a nuestro alrededor con detenimiento y atención para entender el porqué de las cosas. Nuestro objetivo es descubrir cuál es el grado de madurez del equipo y la organización en la práctica Scrum.

Durante estos primeros días no debemos ser demasiado intrusivos sino mantenernos al margen para analizar el nuevo ecosistema en el que nos encontramos, sin alterarlo, y componer una foto mental que nos ayude a identificar aspectos fuertes y aquellos que necesitan ser trabajados.

Además, esta toma de contacto nos permitirá conocer a nuestros nuevos compañeros así como al resto de personas con las que interactúan y que tienen influencia en el equipo, el proyecto y la organización.

Antes de arrancar necesitamos tener claro qué queremos hacer y sobre todo por qué queremos hacerlo, siendo esta fase de observación la base para ello. La duración de este periodo dependerá de cada situación pero en general 2 semanas parece un tiempo razonable para recoger la suficiente información como para ponernos manos a la obra.

 

 CREACIÓN DE NUESTRO BACKLOG

Una vez tengamos claro el contexto en el que nos movemos comenzaremos a elaborar nuestro plan de trabajo. Este plan no será rígido ni quedará cerrado sino que haremos una primera aproximación que posteriormente iremos ampliando y adaptando.

Una técnica útil es escribir en post-its cada uno de los puntos que queremos trabajar para después ordenarlos en función del impacto que esperamos y los beneficios que aportarán.

Usaré como ejemplo uno de los últimos proyectos en los que he participado. El equipo ya había estado trabajando con Scrum durante unos meses antes de mi incorporación por lo que no partíamos de cero, parte del camino ya estaba recorrido. En esta ocasión conté con la colaboración de mi compañero David y juntos identificamos los siguientes temas:

Improvement itemsEl siguiente paso fue priorizarlos, teniendo muy claro cuáles eran los primeros que queríamos abordar y haciendo una ordenación orientativa del resto. En este momento no dimos profundidad a ninguno de ellos ni planteamos cómo se iban a trabajar, nuestro objetivo era tener una lista ordenada de elementos que sirvieran como base para ponernos en marcha. Ya teníamos nuestro Backlog 🙂

Los items del backlog dependerán del contexto en el que estemos y de la situación que hayamos identificado. Si el equipo y la organización están dando sus primeros pasos con Scrum será necesario centrar nuestros esfuerzos en formaciones, para asegurar que el framework se comprende e interioriza, así como empezar a introducir aspectos básicos. En el lado opuesto, si el grado de madurez es alto tendremos que poner el foco en la búsqueda de acciones de mejora, tanto técnicas como de proceso, para impulsar que se siga progresando.

 

REFINAMIENTO

Ya tenemos claros cuáles son los puntos que queremos trabajar, ahora es el momento de darle profundidad y detalle a los primeros elementos de nuestro backlog.

Para ello nos plantearemos preguntas como: qué quiero conseguir, cuál va a ser la estrategia a seguir, qué tipo de técnica o dinámica es la más adecuada, qué implicación es necesaria por parte de cada uno de los roles del equipo, cómo vamos a medir el impacto que produce, etc.

Refinamiento DoR

Reflexionar sobre estas cuestiones y otras que nos irán surgiendo nos permitirá dar forma y preparar nuestras sesiones de trabajo. Si durante la definición del backlog nos centrábamos en el qué y el porqué, ahora es el momento de preocuparnos por el cómo.

 

EJECUCIÓN, INSPECCIÓN Y ADAPTACIÓN

El siguiente paso es poner en marcha las sesiones que hemos preparado, observar los cambios que se producen y determinar si obtenemos el resultado esperado. Además de nuestra percepción personal pediremos feedback a todos los involucrados, especialmente al equipo. Un buen momento para recoger y comentar sus impresiones es la retrospectiva, aunque no tenemos que esperar necesariamente a esta reunión, pudiendo hacerlo en cualquier otro instante. En caso de ser necesarias nuevas acciones de refuerzo las añadiremos a nuestro backlog y re-priorizaremos.

Así, tras haber trabajado el Definition of Ready, podría ocurrir que éste fuera demasiado estricto o demasiado flexible. En ninguno de los casos sería útil, limitaría en exceso las historias de usuario que consideramos listas para añadirse al sprint en el primer caso, y no tendría condiciones suficientes para asegurar que podemos empezar a trabajar en ellas en el segundo.  Añadiremos un item a nuestro backlog: ajustar el DoR para que cumpla adecuadamente su función, y lo colocaremos en la posición que le corresponda, en función de su prioridad respecto al resto de temas.

Como comentamos al principio, el backlog es un elemento vivo que va evolucionando, adaptándose y creciendo con nuevas oportunidades de mejora resultado de la experimentación, inspección y aprendizaje.

 

TRANSPARENCIA

Es importante que nuestro plan de trabajo, nuestro backlog y el estado de cada elemento, sea público y accesible. Esto es útil para mucha gente:

  • para el equipo, que conoce en todo momento cuáles son los elementos a trabajar y se favorece su involucración
  • para otros Scrum Masters en la organización, pudiendo ser uno de los temas a tratar en las comunidades de prácticas
  • para management, que necesita tener visibilidad sobre las acciones que realizamos
  • para todos aquellos que no usan Scrum, llamando su atención y generando curiosidad.

Tablón Scrum Master

 

REFLEXIÓN FINAL

 El objetivo de este post es compartir una estrategia para definir un plan de trabajo flexible, ante el reto de impulsar y consolidar la práctica Scrum, en un entorno que es nuevo para nosotros.

Por otro lado, este plan solo cubre una parte de las responsabilidades de un Scrum Master, ya que adicionalmente deberemos facilitar las reuniones y hacer que sean efectivas, eliminar impedimentos, proteger al equipo de interrupciones externas y un largo etcétera que forma parte de nuestro día a día.

Y vosotros, ¿qué estrategia utilizáis al incorporaros como Scrum Master en un nuevo equipo?

También te puede interesar.

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

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

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.

¿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.

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Plan para formar a Scrum Master propios de la empresa

En todo acompañamiento en la transformación a la agilidad con Scrum, llega un momento en que los Agile Coach y Scrum Master externos a la empresa deben dejar al Cliente que siga su camino. Y con garantías de que no se va a perder lo conseguido y se va a seguir fomentando la mejora continua y el customer centric.

¿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?

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.

Scrum ayuda a la mejora de la calidad en los productos

Scrum es simple e incompleto, solo define las partes necesarias para implementar la teoría de Scrum, permitiendo a las personas que lo utilizan generar sus propias instrucciones para conseguir alcanzar sus metas y crear valor. Y ahí está la dificultad para aprender a usarlo y mejorar la calidad de nuestros productos.

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