Seamos ágiles con Scrum (V) – conceptos básicos: El Scrum Master, el equipo de desarrollo, y Scaled Scrum
on Tue Jun 01 2021
Gentil introducción
Este serie de publicaciones describe paso por paso los conceptos más importantes de Scrum, así como la forma en que pueden ser aplicados en una organización real.
Puedes acceder a toda la serie a través de estos enlaces:
Primera parte – El agilismo y el manifiesto ágil.
Segunda parte – Conceptos básicos: La guía de Scrum, Product Backlog, Items y User Stories
Cuarta parte – Cómo medir el progreso de desarrollo
Quinta parte – Conceptos básicos: El Scrum Master, el equipo de desarrollo, y Scaled Scrum
Sobre la guía de Scrum 2020: Esta serie de publicaciones se encuentra en construcción, y su contenido se basa íntegramente en la guía de Scrum de 2017. Finalizada la publicación de la serie, se trabajará en actualizar el contenido a la última versión de la guía de Scrum.
Qué esperar de esta publicación
En la publicación anterior profundizamos en algunas recomendaciones para estimar la duración del desarrollo, y comentamos por qué no era recomendable, entre otras cosas, estimar pensando únicamente en el tiempo de desarrollo, o comparar velocidades de distintos equipos.
Esta publicación continuará introduciendo conceptos básicos, e introducirá el rol del Scrum Master, el equipo de desarrollo, y comentará brevemente aspectos a tener en cuenta cuando el número de desarrolladores es elevado.
El Scrum Master: Un líder que «sirve» a los demás, o líder coach
En las anteriores publicaciones se han introducido diferentes conceptos relativos a Scrum, y en las sucesivas seguirán apareciendo nuevos conceptos, roles, eventos y artefactos. Todos ellos, conforman la forma en que Scrum debe articularse en un equipo.
¿Y quien debe asegurarse de que Scrum se siga de la forma idónea? Esa persona es el Scrum Master.
El Scrum Master es una persona parte del Scrum Team, que principalmente asume dos responsabilidades:
- Asegurarse de que el framework de Scrum se utiliza y sigue de forma correcta.
- Actuar como facilitador, y ayudar a eliminar los impedimentos que pueda tener el Scrum team.
Se define al Scrum Master cómo un líder que «sirve» a los demás, o como un líder coach, ya que su principal medio de actualización es el análisis, la enseñanza y argumentación.
Plasmándolo de otra forma: Si el Scrum Master observa, por ejemplo, que los desarrolladores dejan de asistir a los dailies (lo cual por cierto, consituye un Scrumbut), su actitud no debe ser imperativa. Debe preguntarse en primer momento, qué puede estar motivando esta situación, a continuación debe tratar de eliminar los impedimentos que están privando a los desarrolladores de poder asistir a los dailies, y en el caso de que se trate de que éstos voluntariamente no quieren asistir, debe explicarles la importancia de los dailies, y a través de los argumentos y beneficios que claramente ofrece estar sincronizados, convencerlos para que asistan nuevamente.
Esta forma de actuar, en la que la escucha activa, enseñanza y argumentación sean la forma habitual de actual, forma parte del día a día de un Scrum Master.
Scaled Scrum: Cuando existe un gran número de desarrolladores
El equipo de desarrollo debe estar conformado por, de 3 a 9 desarrolladores.
Menos de tres personas constituiría un equipo demasiado pequeño para la implementación de Scrum. Los beneficios se reducirían ante un equipo tan pequeño, y el esfuerzo que supondría implementar y mantener un framework ágil como Scrum serían los mismos.
Un equipo mayor a nueve desarrolladores, sería difícil de gestionar. Recordemos que en Scrum los equipos de desarrollo son auto-organizados, altamente cohesionados y auto-responsables, y esa auto-responsabilidad y auto-organización va en detrimento de una jerarquía y organización estricta, con lo cual en la práctrica, en un entorno de estas características, cuando el equipo se conforma por muchas personas, la organización puede empezar a no ser óptima.
¿Y qué sucede cuando se necesita un equipo de más de nueve personas? Es aquí cuando debemos desplegar lo que se denomina Scaled Scrum.
En Scaled Scrum, disponemos de más de un equipo de desarrollo. Podríamos resumirlo, a grandes rasgos diciendo que en Scaled Scrum disponemos de:
- Un sólo Product Owner: Dado que en el caso de disponer de más de uno, la tutela y dirección del producto no dispondrá de un rumbo fijo.
- Uno o más Scrum Masters: Que podrán además formar parte de más de un proyecto simultáneamente.
- Uno o más equipos de desarrollo.
Asimismo, de igual forma que sólo disponemos de un único Product Owner, dispondremos de un único Product Backlog para el proyecto. No obstante, cada equipo dispondrá de su propio Sprint Backlog.
Al finalizar el Sprint, cada equipo de desarrollo combinarán el sofware generado durante todo el Sprint, y generarán un único incremento.
Conclusión
Ahora sabemos quien es el Scrum Master, y cuál es su cometido. Además, sabemos cuántas personas pueden formar parte del equipo de desarrollo, y tenemos una idea superficial de cómo podemos articular varios equipos de desarrollo en un mismo proyecto.
En la siguiente publicación observaremos los elementos que podemos encontrar en el Sprint Backlog, el momento en el que componemos el Sprint Backlog, realizaremos un breve repaso a todos los eventos que conforman un Sprint (de los cuales ya hemos avanzado algunos) y clarificaremos exactamente quien debe ser considerado parte del equipo de desarrollo.