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.

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?

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

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?

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

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.

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.

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

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.

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.

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.

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