El equipo Scrum

Un Equipo Scrum consiste en un Propietario del Producto (Product Owner), un Scrum Master y los Developers; y se trata de una unidad cohesionada de profesionales centrados en un objetivo a la vez: el Objetivo de Producto (Product Goal).

Los Equipos Scrum son auto-gestionados y multifuncionales. El modelo de Equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades para poder obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.

Tamaño del Equipo Scrum

El tamaño óptimo de un Equipo Scrum es 10 personas o menos, esto le permite ser lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para poder completar una cantidad significativa de trabajo.

Consideraciones:

No se recomienda tener menos de 3 miembros en el Equipo pues se reduce la interacción y resulta en baja productividad.
Los Equipos más pequeños pueden encontrar limitaciones en cuanto a las habilidades necesarias durante un Sprint, haciendo que el Incremento pudiese no ser significativo para el cliente.
Tener más de 10 miembros en el equipo requiere demasiada coordinación.
Los Equipos muy grandes generan demasiada complejidad y dificultades en la comunicación como para que un proceso empírico pueda ser de utilidad.
Los roles de Product Owner y Scrum Master no se cuentan como Developers, a menos que también estén contribuyendo al desarrollo del trabajo durante el Sprint.

1. El Product Owner (Dueño de Producto)

El Product Owner es el responsable de maximizar el valor entregado por los Developers
Es el representante de todos los interesados (stakeholders) en los resultados del producto
Actúa como interlocutor único ante el equipo Scrum, con autoridad para tomar decisiones.
Es el encargado de garantizar los resultados del producto.
El Product Owner (P.O) es una única persona, no un comité.
Es considerado como “La voz del cliente”
Es la única persona responsable de gestionar el Product Backlog.

La gestión del Product Backlog incluye:

Expresar claramente los elementos del Product Backlog.
Ordenar los elementos en el Product Backlog para alcanzar los objetivos y las misiones de la mejor manera posible.
Garantizar que el Product Backlog sea visible, transparente y clara para todos y que muestre, lo que el equipo trabajará a continuación.
Asegurar que los Developers entienden los elementos del Product Backlog a nivel necesario.
El Product Owner es una única persona, no un comité. El Product Owner podría representar los deseos de un comité en el Product Backlog, pero aquellos que quieran cambiar la prioridad de un elemento del Product Backlog deben hacerlo a través del Product Owner.

Para que el Product Owner pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones. Las decisiones del Product Owner se reflejan en el contenido y en la priorización del Product Backlog.

Responsabilidades del Product Owner

Participar en las reuniones de planificación y revisión de las iteraciones (sprints).
Entender las necesidades de las partes interesadas para posteriormente levantar los requerimientos que harán parte del Product Backlog.
Mantener comunicación frecuente con el cliente (ya que es el único punto de contacto entre el cliente y el Equipo Scrum).
Gestionar los riesgos globales del proyecto.
Presentar informes del proyecto al cliente u otras partes interesadas.
Aprobar cambios en el proyecto.
Asegurar que se administran correctamente los recursos financieros del proyecto al inicio y durante su ejecución.
Participar en las reuniones de apertura y cierre del proyecto.

Normalmente el rol del Product Owner se asocia con un Gerente de Proyecto, dadas sus responsabilidades de gestión, sin embargo, estos roles NO son iguales. Es más preciso asociarlo al rol que representa “La voz del cliente”.

2. Desarrolladores (Developers)

Los Developers son los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” (Done) que potencialmente se pueda poner en producción al final de cada Sprint. Solo los Developers participan en la creación del Incremento.

Responsabilidades de los Developers

Crear un plan para el Sprint: el Sprint Backlog
Asegurar la calidad con el cumplimiento de la Definición de Terminado (Definition of Done)
Adaptar su plan de trabajo diario para alcanzar el Objetivo del Sprint (Sprint Goal)
Responsabilizarse del trabajo.

Nota: Se llaman “Desarrolladores”, porque desarrollan el producto (no necesariamente software)

La organización es la encargada de estructurar y empoderar a los Developers para que estos organicen y gestionen su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del Equipo Scrum en conjunto.

Los Developers tienen las siguientes características:

Son autogestionados. Nadie (ni siquiera el Scrum Master) les da órdenes o imposiciones sobre cómo convertir elementos del Product Backlog en Incrementos de funcionalidad potencialmente desplegables.
Nadie fuera del Scrum Master y el Product Owner puede pedir a los Developers que trabajen en un conjunto diferente de requisitos que previamente hayan sido planeados y acordados.
Los Developers son multifuncionales, con todas las habilidades necesarias para crear un Incremento de producto.
Scrum no reconoce títulos para los miembros de un Equipo Scrum, independientemente del trabajo que realice cada persona, quienes ejecuten el trabajo necesario para construir el producto se conocen como Developers.
No existen sub-equipos en el Equipo Scrum, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas, aseguramiento de calidad, arquitectura, operaciones, o análisis de negocio.
Los Developers pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad del producto recae sobre los Developers como un todo.

3. El Scrum Master (Maestro Scrum)

El Scrum Master es un facilitador, responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Su principal responsabilidad entonces es garantizar que todos conocen y aplican correctamente la teoría y práctica de Scrum.

El Scrum Master es un líder que sirve al Equipo Scrum y en general a toda la organización.
El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no.

El Scrum Master al servicio del Equipo y los Desarrolladores (Developers)

El Scrum Master sirve a los desarrolladores de varias formas, incluyendo:

Guiar a los Desarrolladores para que aprendan a ser autogestionados y multifuncionales.
Ayudar a los Desarrolladores a centrarse en crear productos de alto valor además de cumplir con la Definición de Terminado.
Eliminar impedimentos para el progreso de los Desarrolladores.
Facilitar los eventos de Scrum según se requiera o necesite, para que sean productivos, respetando el tiempo designado para cada uno (time-box).
Guiar a los Desarrolladores en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.

El Scrum Master al servicio del Product Owner

El Scrum Master sirve al Product Owner de varias formas, incluyendo:

Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el Equipo de la mejor manera posible.
Ayudar a encontrar técnicas para gestionar el Product Backlog, definir el Objetivo de Producto (Product Goal) y gestionar los atrasos en el producto.
Ayudar al Equipo Scrum a entender la necesidad de contar con elementos del Product Backlog claros y concisos.
Entender la planificación del producto en un entorno empírico y complejo.
Ayudar a entender y practicar la agilidad.
Facilitar la colaboración de las partes interesadas y/o cliente según sea necesario.

El Scrum Master al servicio de la Organización

El Scrum Master sirve a la organización de varias formas, incluyendo:

Liderar y guiar a la organización en la adopción de Scrum.
Planificar y asesorar en la adopción de Scrum en la organización.
Ayudar a los empleados e interesados a entender y poner en práctica un enfoque empírico en el desarrollo del trabajo.
Motivar cambios que incrementen la productividad en la organización.
Junto con otros Scrum Masters, incrementar la efectividad de la adopción de Scrum en la organización.
Eliminar las barreras de comunicación entre los Equipos Scrum y las diferentes partes interesadas.

Scrum NO considera el rol tradicional de “Gerente del Proyecto”. Entonces, ¿a dónde van estos empleados? Lo más frecuente y natural es que los Gerentes de Proyecto hagan una transición hacia Product Owners e incluso a Scrum Masters. Sin embargo, muchos buenos Scrum Masters provienen de los desarrolladores y QA; por lo tanto el Scrum Master no es ni remotamente parecido al del Gerente de Proyecto, y por esto es importante que el candidato a Scrum Master adquiera capacitación en Scrum.

El Scrum Master debe aceptar que el equipo es dueño de la agenda de trabajo, así que no más actualizar los viejos Diagramas de Gantt. Debe alentar al equipo para que mantenga actualizadas sus estimaciones diarias. El Scrum Master asegura que se siga el proceso de Scrum, que todos entienden Scrum y cómo funciona.

El Scrum Master debe quitar impedimentos, o asistir en quitar impedimentos, lo más rápido posible.

Se asegura que el equipo se mantiene en rumbo, recordándole al equipo el objetivo del Sprint en cada reunión.

Organiza los Scrums diarios (Reunión diaria), y se asegura que se realice en el mismo lugar a la misma hora.

Traducido de Coping with change on Scrum projects, por Jack Milunksy.

Comunicación en el equipo