La mayoría de los equipos ágiles usan Scrum, y Scrum tiene exactamente tres roles: un Product Owner, un Scrum Master y los Developers (los desarrolladores), que hacen el trabajo. Todos los demás que tienen algo en juego en el producto, desde los clientes hasta los managers, trabajan con el equipo, pero no forman parte de él.
Los roles son fáciles de enumerar y fáciles de desdibujar. El Product Owner acaba siendo un comité, el Scrum Master se convierte en quien toma notas para el equipo y los Developers esperan a que alguien les diga qué hacer después. Esta guía explica de qué se encarga y qué decide cada rol, tal como los define la Guía de Scrum, quién más trabaja alrededor del equipo, cómo funcionan los roles en Kanban y quién hace qué en cada reunión, con un equipo de ejemplo.
Los tres roles de un vistazo
| Rol | Responsabilidad | Decide | No es |
|---|---|---|---|
| Product Owner | El valor del producto: el Objetivo del Producto y el Product Backlog | En qué trabaja el equipo a continuación, y en qué orden | Un comité, ni un intermediario que no puede decir que no |
| Scrum Master | La eficacia del equipo y su buen uso de Scrum | Nada sobre el producto; ayuda al equipo a decidir cómo mejorar | El jefe del equipo, ni su secretario |
| Developers | Un incremento utilizable por sprint, que cumple la Definition of Done del equipo | Cómo hacer el trabajo, y quién hace cada parte | Personas que esperan a que les repartan tareas |
La edición 2020 de la Guía de Scrum las llama responsabilidades (accountabilities) en lugar de roles, y sustituyó el antiguo «equipo de desarrollo» (Development Team) por «Developers», de modo que un equipo Scrum es un solo equipo, sin subequipos. La mayoría de la gente sigue diciendo roles, y esta guía también.
Product Owner
El Product Owner es responsable del valor de lo que construye el equipo. En la práctica, eso significa encargarse del Product Backlog, la única lista ordenada de todo lo que el producto podría necesitar, y ser quien decide qué va primero. La Guía de Scrum divide ese trabajo en cuatro partes:
- Definir el Objetivo del Producto (Product Goal), el objetivo a más largo plazo hacia el que avanza el backlog, y asegurarse de que todos lo conozcan.
- Escribir los elementos del backlog, o encargar que se escriban, para que el equipo entienda para qué sirve cada uno.
- Ordenar el backlog, para que el trabajo más valioso vaya primero.
- Mantener el backlog visible y comprensible para todos los que tienen algo en juego en él.
El Product Owner es una persona, no un comité. Ventas, soporte y el CEO pueden intentar cambiar el orden del backlog, pero tienen que hacerlo convenciendo al Product Owner. El Product Owner puede pasar parte del trabajo a otros, como escribir los elementos, y sigue siendo responsable del resultado. Por eso el rol necesita a alguien con autoridad para decir que no, y con tiempo para hablar con clientes y stakeholders todas las semanas.
Scrum Master
El Scrum Master es responsable de la eficacia del equipo, y de que el equipo use Scrum como se debe usar. La Guía de Scrum dice que los Scrum Masters son «verdaderos líderes que sirven al Scrum Team y a la organización en general», y ese servicio va en tres direcciones:
- Al equipo: lo guía para que se autogestione, lo mantiene centrado en terminar trabajo que cumpla la Definition of Done, consigue que se eliminen los impedimentos y se asegura de que las reuniones se hagan, sean útiles y no se pasen de tiempo.
- Al Product Owner: lo ayuda con formas de definir el Objetivo del Producto y de mantener el backlog claro y ordenado.
- A la organización: ayuda a los managers y a otros equipos a entender cómo trabaja el equipo, y elimina los obstáculos entre ellos.
Un Scrum Master no asigna trabajo, no fija plazos ni evalúa a las personas. Cuando el equipo pregunta «¿quién debería encargarse de esto?», un buen Scrum Master le devuelve la pregunta al equipo. Un Scrum Master puede servir a más de un equipo, y en un equipo pequeño el Scrum Master a menudo también trabaja en el producto: la Guía de Scrum dice que un Product Owner o un Scrum Master que trabaja en elementos del sprint participa como Developer.
Developers
Los Developers son todas las personas del equipo que construyen el producto: ingenieros, diseñadores, testers, redactores, analistas. El nombre no tiene que ver con el código. Juntos, son responsables de:
- Planificar el sprint: elegir el trabajo y decidir cómo hacerlo.
- Construir según la Definition of Done del equipo, el estándar común que dice cuándo un trabajo está terminado.
- Ajustar el plan cada día para alcanzar el Objetivo del Sprint.
- Exigirse ese estándar unos a otros.
Los Developers se gestionan solos. Nadie de fuera del equipo les dice quién hace cada tarea; lo deciden juntos, y comparten la responsabilidad del resultado. El equipo también es multifuncional: entre todos, los Developers tienen todas las habilidades necesarias para terminar un elemento, así que nada espera a un equipo de diseño o de pruebas aparte.
¿Cuántas personas tiene un equipo ágil?
La Guía de Scrum dice que un equipo Scrum tiene «generalmente 10 personas o menos», contando al Product Owner y al Scrum Master. La edición anterior hablaba de tres a nueve Developers. Por encima de ese tamaño, la comunicación se vuelve lenta y la reunión diaria deja de ser útil. Cuando un producto necesita más gente, divídela en varios equipos que compartan un mismo Objetivo del Producto, un mismo Product Backlog y un mismo Product Owner.
Los roles alrededor del equipo
Scrum solo define los tres roles de dentro del equipo. Muchas otras personas influyen en el trabajo desde fuera:
- Clientes, usuarios y sponsors. Las personas para las que se hace el producto y las que lo pagan. Ven los resultados en la sprint review, y sus comentarios cambian lo que el Product Owner prioriza después.
- Managers. Los jefes directos siguen contratando, desarrollando a las personas y resolviendo los problemas que el equipo no puede resolver solo, como una habilidad que falta o dos prioridades que chocan. No asignan el trabajo del sprint.
- Directores de proyectos. Scrum no tiene un rol de director de proyectos (project manager): el Product Owner se encarga del alcance y las prioridades, los Developers del plan y el Scrum Master del proceso. En la práctica, los directores de proyectos suelen convertirse en Product Owners o Scrum Masters, o coordinan lo que abarca varios equipos, como los presupuestos, los proveedores y las fechas de lanzamiento.
- Agile coaches. Coaches que trabajan con varios equipos y con la dirección, normalmente cuando toda una empresa cambia su forma de trabajar.
- Especialistas compartidos. Un experto en seguridad o un analista de datos que ayuda a varios equipos trabaja con cada uno cuando hace falta, sin ser uno de sus Developers.
Los marcos de trabajo para escalar la agilidad a muchos equipos añaden roles para coordinarlos; el más conocido es el Release Train Engineer de SAFe. Un solo equipo no necesita ninguno de ellos.
Roles en Kanban
Kanban no prescribe ningún rol. La Guía Kanban pide a un equipo que haga visible su trabajo, limite el trabajo en curso y gestione activamente cómo fluye el trabajo, y no dice nada de los cargos. Un equipo que adopta Kanban mantiene los roles que ya tiene.
El Método Kanban de Kanban University describe dos roles opcionales, que se corresponden bastante con los de Scrum: un service request manager, que decide qué trabajo entra a continuación, como un Product Owner, y un service delivery manager, que hace que el trabajo fluya, como un Scrum Master.
Ejemplo: un sprint en Kestrel Travel
Kestrel Travel es una empresa ficticia con una app de viajes. Su equipo de check-in tiene siete personas y trabaja en sprints de dos semanas hacia un solo Objetivo del Producto: los viajeros pueden hacer el check-in de cualquier vuelo desde la app.
| Persona | Rol | Qué más hace |
|---|---|---|
| Ana | Product Owner | Habla con los viajeros y con el equipo de alianzas con aerolíneas todas las semanas |
| Ravi | Scrum Master | También trabaja con el equipo de pagos |
| Lena, Marco, Joy | Developers | Los ingenieros de iOS, Android y back-end |
| Sam | Developer | El diseñador |
| Kofi | Developer | Prueba la app en teléfonos reales |
Para el sprint 9, Ana propone el siguiente paso más valioso: que un viajero con un vuelo de solo ida pueda hacer el check-in y llevar la tarjeta de embarque en el teléfono. Esto es lo que hace cada uno en cada reunión del sprint:
| Reunión | Ana, Product Owner | Ravi, Scrum Master | Los Developers |
|---|---|---|---|
| Sprint planning | Explica por qué el check-in de solo ida es lo más importante ahora, y responde a las preguntas | Hace que la reunión no se pase de tiempo y que termine con un plan | Eligen los elementos que pueden terminar, acuerdan con Ana el Objetivo del Sprint y planifican el trabajo de los primeros días |
| Daily scrum | No necesita asistir | Se asegura de que se haga y de que no dure más de 15 minutos | Revisan el avance hacia el Objetivo del Sprint y cambian el plan si hace falta |
| Refinamiento del backlog | Explica los siguientes elementos y reordena el backlog | Enseña al equipo a dividir los elementos grandes | Hacen preguntas, estiman los elementos y dividen los que son demasiado grandes |
| Sprint review | Invita a los stakeholders y comenta qué cambia en el backlog | La facilita, si el equipo se lo pide | Muestran el check-in funcionando y escuchan los comentarios de los stakeholders |
| Retrospectiva | Participa como un miembro más del equipo | La facilita | Eligen uno o dos cambios para probar en el siguiente sprint |
El segundo día, Joy descubre que el equipo todavía no tiene una cuenta de prueba para el sistema de check-in de la aerolínea. Lo plantea en la daily scrum, y Ravi se encarga: conseguir la cuenta pasa a ser su trabajo, para que los Developers no se pasen el sprint persiguiéndola.
Organiza los roles en Redbooth
Los roles se mantienen mejor cuando el tablero muestra de quién es cada cosa. En Redbooth, el equipo de Kestrel usa un espacio de trabajo para el producto de check-in, con todo el equipo como miembros, y tres listas de tareas:
- Product Backlog, a cargo de Ana. Cada elemento es una tarea, con los detalles en su descripción y las preguntas en sus comentarios. Ana mantiene arriba los elementos más valiosos.
- Una lista por sprint. En la sprint planning, los Developers pasan a «Sprint 9» los elementos que eligen, dividen cada uno en subtareas, se las asignan y les ponen fechas dentro del sprint.
- Impedimentos, a cargo de Ravi. Todo lo que bloquea al equipo se convierte en una tarea asignada a él, para que nadie tenga que plantear el mismo problema en cada daily scrum, y todos puedan ver cuándo se ha resuelto.
En la vista de tablero, las tres listas están una al lado de la otra, y cada tarjeta muestra a quién está asignada:
Si el equipo pone sus roles por escrito, el lugar para hacerlo es un team charter, junto con cómo decidirá el equipo cuando no esté de acuerdo.
Errores que desdibujan los roles
- Un comité como Product Owner. Cuando tres managers comparten el rol, el backlog no tiene orden, y el equipo aprende a esperar a que se pongan de acuerdo.
- Un Product Owner que no puede decidir. Un intermediario que consulta cada decisión con otra persona ralentiza todos los sprints.
- Un Scrum Master que hace de jefe. Asignar tareas y perseguir fechas enseña al equipo a dejar de gestionarse solo.
- Equipos dentro del equipo. Un grupo de pruebas aparte al final del sprint trae de vuelta los traspasos que Scrum pretende eliminar.
- Personas repartidas en demasiados equipos. Quien está en cuatro equipos no pertenece a ninguno, y cada equipo planifica contando con su ausencia.
Preguntas frecuentes
¿Cuáles son los tres roles de Scrum?
El Product Owner, que decide en qué trabaja el equipo y en qué orden; el Scrum Master, que hace que el equipo sea eficaz; y los Developers, que construyen el producto. La Guía de Scrum los llama responsabilidades.
¿Quiénes son los miembros de un equipo ágil?
Todas las personas necesarias para convertir los elementos del backlog en un resultado terminado y utilizable. En Scrum, son el Product Owner, el Scrum Master y los Developers, generalmente diez personas o menos en total. Los clientes, los sponsors y los managers trabajan de cerca con el equipo, pero no forman parte de él.
¿El Scrum Master es un director de proyectos?
No. Un Scrum Master no planifica el trabajo, no lo asigna ni evalúa a las personas; los Developers planifican su propio trabajo, y el Product Owner decide las prioridades. El Scrum Master guía al equipo y elimina lo que lo frena.
¿Pueden ser la misma persona el Product Owner y el Scrum Master?
La Guía de Scrum no lo prohíbe, pero rara vez es buena idea. El Product Owner busca el máximo valor; el Scrum Master protege la forma de trabajar del equipo. Una persona que hace las dos cosas suele perder una de esas dos voces.
¿Kanban tiene roles?
No. La Guía Kanban no prescribe roles, así que un equipo mantiene los que tiene. El Método Kanban describe dos opcionales, el service request manager y el service delivery manager.
Antes de tu próxima sprint planning, hazle tres preguntas al equipo: quién ordena el backlog, quién elimina lo que nos bloquea y quién decide cómo se hace el trabajo. Si las respuestas no son un nombre, un nombre y «todos nosotros», empieza por ahí.