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.

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