Para que un equipo autogestionado logre sus objetivos con agilidad, en Scrum se proponen tres roles con diferentes responsabilidades.
Guardián del Producto/Prestación (Product Owner)
- Comunicar con claridad y marcar el rumbo: es el responsable que el Producto/Prestación sea valioso, por eso es necesario que conozca en profundidad el negocio o el tema involucrado, conocer el producto, ser el que tiene directamente la necesidad o alguien que esté muy cerca de quienes la tienen.
- Sea siempre una sola persona, y si hay varios interesados en el Producto/Prestación sea el encargado de relevar y chequear lo analizado con ellos, y cada ítem analizado pasa a una lista de necesidades identificadas (Backlog). Por eso a veces se representa con la metáfora del embudo: recibe distintas entradas, las transmite al equipo en forma priorizada, cuida que se conviertan en el mayor valor posible.
- Tomar decisiones y resolver conflictos de intereses o de criterios de priorización (cuida que el equipo no pierda tiempo por estos motivos).
- Estar siempre disponible para responder las dudas y tomar decisiones claras sobre los temas más grandes: la visión, las necesidades y las prioridades.
- Ser proactivo para mantener a todos informados de los cambios.
- Ser abierto a las propuestas de solución que el equipo presenta y ofrece retroalimentación clara para mejorarlas.
- Consultar y recibir retroalimentación sobre la mejor forma de comunicar y explicar las necesidades (historias de usuarios).
- Respetar al equipo: no meterse en el cómo resolver las tareas (esto es responsabilidad del equipo, es mejor no limitar su creatividad).
Equipo
- Está compuesto por distintas personas, que entre todas contienen todas las habilidades y conocimientos necesarios para resolver las necesidades.
- El equipo entero asume el compromiso de cuántas y cuáles necesidades responder, y en un determinado período de tiempo. Es el responsable de las estimaciones y el tiempo les va dando mayor precisión.
- Cada persona asume las tareas (“la libre elección genera entusiasmo y compromiso”) y ante las más complejas el equipo entero decide cómo resolverlo. Pueden dos personas asumir una misma tarea, y ambas son responsables de su cumplimiento.
- El equipo chequea con el Guardián del Producto/Prestación si está entendiendo bien la visión y las necesidades, y va mostrando el avance para confirmar que estén avanzando en la dirección correcta. Respeta al Guardián del producto, lo que especifica y las prioridades que define.
Facilitador (Scrum Master)
- Su rol principal es brindar herramientas, transmitir conocimientos, y colaborar en todo lo que sea posible para que el equipo alcance su máximo rendimiento.
- Resuelve impedimentos para el trabajo en equipo o la concreción de los resultados.
- Estimula el aprendizaje y respalda el desarrollo personal.
- Observa las prácticas de cada uno del equipo y alienta a mejorarlas.
- Promueve la mejora continua del equipo.
- Explica y ayuda a implementar distintas formas de organizar el trabajo.
- Chequea que se apliquen las prácticas de Scrum, y las adapta cuando sea necesario.
- Si identifica requerimientos de normas ISO o de políticas de la empresa que generan trabajo y no valor: analiza la situación, realiza propuestas de mejora y acuerdos de trabajo, respondiendo a las necesidades metodológicas de toda la organización (y no sólo del equipo).
- Enseña al Guardián del Producto (PO) a redactar con precisión la visión y el listado de necesidades (Backlog).
- Puede ser un miembro del equipo o varios que realicen estas tareas.
- Puede ser una persona externa que observe y ayude al equipo a auto conocerse, por determinados períodos de tiempo o en algunos eventos como son las reuniones.
- Respeta al Guardián del producto y al equipo: propone, pero no impone.
Algunas aclaraciones para el desarrollo de software
- Es indispensable un Product Owner (PO)
- Aclaración: Si en el proyecto hay varios interesados, con perfiles funcionales y comerciales, sus aportes y revisiones deberán estar canalizadas y organizadas a través del PO. Puede ser un “PO Proxy”, es decir, alguien del área de Sistemas que se encargue de comunicarse con los referentes del negocio y resuelva las tareas del PO (la desventaja es que hay pérdida de tiempos e información por tener mayor distancia del negocio)
- Motivo: Es la voz del negocio en el proyecto, y es quien tiene la visión completa de lo solicitado. Si hay varios referentes del negocio, es difícil priorizar las historias e implica pérdidas de tiempo para el equipo técnico en que se pongan de acuerdo.
- El equipo está integrado por todos los perfiles necesarios para satisfacer las historias de usuario
- Aclaración: Es decir, el equipo tiene que responder en tiempo y forma, además del desarrollo, a las tareas de análisis y testing.
- Motivo: El equipo tenga autonomía para avanzar y cumplir con lo planificado. Es decir, no dependan de personas que están fuera del equipo con temas o proyectos más prioritarios que las tareas del sprint (= ciclo de trabajo).
- El PO necesita contar con tiempo para probar la aplicación cada vez que el equipo técnico se lo requiera (si lleva demasiado tiempo se recomiendan las pruebas automatizadas, siempre antes haya pruebas unitarias del equipo). Es importante que el equipo lo pida, con tiempo suficiente para corregir, antes de la entrega, los errores que encuentren.
- Motivo: Para mitigar el riesgo de malos entendidos y corregir lo antes posible.
- Haya un mínimo de 2 desarrolladores, y si pueden ser 3 o 4 mejor.
- Motivo: Se necesitan por lo menos 2 desarrolladores para hacer planning pocker (estimaciones cruzadas), y para que haya intercambio de conocimientos y diseño de mejores soluciones técnicas.
- Sugerido que haya un Scrum Master (SM)
- Motivo: Pueden ser varios quienes resuelvan las tareas del SM, puede ser un rol rotativo.
- Incluyendo PO y SM sea un mínimo de 4
- Motivo: Menos de 4 es difícil que sean interesantes las Retrospectivas y las Daily Meeting, es decir, que surjan puntos para colaborar con los demás y para mejorar como equipo.
- El equipo sea de un máximo de 7 personas. Si es un proyecto que requiere más personas se puede dividir en partes con varios equipos de trabajo y puede haber personas que estén en más de un equipo.
- Motivo: Para ser eficientes con la autogestión, ya que más de 7 se ha comprobado que se generan distracciones y pérdidas de tiempo.
- Las asignaciones del equipo al proyecto sean del 100%
- Motivo: Ganar eficiencia y facilitar la estimación. Y evitar los inconvenientes que el otro proyecto o tareas puedan requerir más tiempo del esperado y que no se cumplan los compromisos con el sprint.