Aprendiendo en un Equipo Scrum

La creación de un equipo Scrum es un proceso complejo en el que se unen diferentes personas con el objetivo de construir en cada iteración un incremento de producto para los usuarios. Dentro del equipo el conocimiento debe ser compartido entre sus integrantes. Por ello, en nuestros clientes fomentamos diferentes prácticas que nos ayudan a este fin.

Si miras dentro de tu equipo Scrum, verás que está compuesto por diferentes personas que, normalmente, tienen diferentes especializaciones. Cada especialización conlleva un conjunto de habilidades y conocimientos que se ponen al servicio del objetivo común.
Sin embargo, necesitas que el conocimiento fluya dentro del equipo evitando que se creen silos de información. Estos silos provocan en el equipo cuellos de botella, ya que sólo aquella/s persona/s con el conocimiento, podrán resolver esos trabajos.

Te pongo un ejemplo: imagina un equipo de baloncesto y las posiciones de sus jugadores: alero, pivot, base, escolta y ala-pivot. Para tener un equipo completo, se necesitan cubrir todas ellas. Además, en función de la posición se necesita un conjunto de habilidades específicas que no todos los jugadores poseen. Sin embargo, hay un mínimo de habilidades comunes como los tiros a canasta, tiros libres, pases, … que todos los jugadores deben tener y practicar para poder aplicarlos en función de la jugada.

Lo mismo ocurre en tu equipo Scrum. Desde la Guía Scrum indican “Los equipos de Scrum son multifuncionales, lo que significa que los miembros tienen todas las habilidades necesarias para crear valor en cada Sprint”. Multifuncional no significa que todos los miembros sean especialistas de todo, si no que el equipo como colectivo reúne todos los conocimientos necesarios para crear el incremento de producto en un sprint. Además, desde nuestra experiencia, te recomendamos que todo el equipo tenga una serie de conocimientos mínimos del resto de especialidades que nos ayuden a tener una mayor flexibilidad y adaptabilidad frente al cambio.

¿Cómo identificar qué conocimientos necesitan ser compartidos en el equipo?

Aquí te proponemos que utilices una matriz de conocimientos. Con ella podrás identificar qué conocimiento necesita ser compartido por el equipo. Para crearla sólo necesitas un listado de las áreas de conocimiento del equipo y una escala para medir el nivel de maestría. Por ejemplo:

Nivel 0 – No tiene conocimientos
Nivel 1 – Tiene algunos conocimientos, pero no puede desarrollar tareas
Nivel 2 – Tiene conocimientos para desarrollar tareas básicas
Nivel 3 – Tiene conocimientos suficientes para desarrollar tareas de forma independiente
Nivel 4 – Maestría

Una vez tengas identificadas las áreas de conocimiento del equipo, registra por cada miembro del equipo cuál es el nivel de maestría en cada una de ellas. De esta forma, obtendrás el nivel de conocimientos de cada miembro del equipo y, además, el nivel de conocimientos por cada área de conocimiento.

matriz conocimientos

En aquellas áreas que identifiques un valor menor, serán en las que el equipo deberá comenzar a compartir conocimientos. Para ello, existen algunas prácticas que te ayudarán:

  • Pair programming. Esta práctica viene de Extreme Programming (XP) y propone trabajar en parejas. El objetivo es que entre los dos construyan la mejor solución posible. Durante la programación de la funcionalidad dos programadores trabajan en el mismo ordenador: uno adquiere el rol de controlador y será el encargado de escribir el código. El otro es el navegador, que dirige la programación y revisa mientras se escribe en busca de errores.
    La asignación de los roles es rotativa, y será la pareja quien decida bajo qué circunstancias se produce ese cambio. Aunque la velocidad del equipo puede disminuir al aplicar esta práctica, el mayor beneficio es la reducción de errores, además de la responsabilidad compartida del código y mejorar la comunicación en el equipo.

 

  • Asistencia a los refinamientos. El refinamiento es el momento en el que el Product Owner y el equipo de desarrollo se unen para aumentar el detalle de los items del Product Backlog. La asistencia de todos los miembros del equipo de desarrollo, hará que todos escuchen las conversaciones. Al principio habrá muchos términos que no nos suenen, pero con el paso de las sesiones nos familiarizaremos con ellos. Además, siempre es bueno contar con nuevos puntos de vista.
    La asistencia a los refinamientos de todos los miembros del equipo tiene efectos en la estimación de los trabajos en la planificación. Si todo el equipo ya conoce el alcance del trabajo y las implicaciones que tiene, es mucho más probable que las estimaciones sean parecidas. Incluso, en el caso en que un especialista no asista, el resto del equipo puede dar una estimación bastante parecida a la que daría su compañero.

 

  • Crear un repositorio único de documentación. A través de la experiencia adquirimos una serie de conocimientos y aprendizajes que utilizamos de forma inconsciente. Seguramente, la primera vez que lo aprendimos lo apuntamos en una libreta y ahora mismo puede estar en el fondo de algún cajón. Esos conocimientos es necesario que se pongan a disposición del equipo. Puede ser a través de un documento compartido, una publicación en un chat dedicado a la formación, una página de Confluence, … Lo importante es que la información esté disponible para todos. Además, es una herramienta de aprendizaje muy importante para las nuevas incorporaciones y permite disminuir el tiempo que las personas del equipo tienen que invertir en formarles, disminuyendo así el impacto en la producción del equipo.

 

  • Sesiones de formación intraequipo. En algunos clientes hemos observado que ante el reto de comenzar a trabajar juntos, se autoorganizan para compartir los conocimientos. Para ello durante el sprint reservan tiempo para la formación, normalmente un par de horas. En ese tiempo, un integrante del equipo repasa algunos puntos relevantes de su especialidad, utilizando casos reales para apoyar los conocimientos. Tanto el material utilizado en la sesión como su grabación son añadidos al repositorio de documentación.

En resumen,

La formación dentro del equipo Scrum debe ser constante, ya que es parte de la mejora constante. El tiempo que se dedica al aprendizaje, puede verse como desperdicio ya que no aporta de manera directa al producto. Pero mientras que se mantengan silos y dependencias en el equipo, estaremos pagando un peaje en cada incremento. Scrum, XP y otras metodologías y marcos dedican parte de sus prácticas o eventos para potenciarlo.

También te puede interesar

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir 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?

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

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.

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.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

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.

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

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.

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

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