En entregas anteriores ya hemos hablado de las generalidades de SCRUM, como una metodología ágil para la gestión de proyectos y en esta ocasión tocaremos el tema de los involucrados de los equipos y varias de las distinciones que facilitan cumplir las metas de forma exitosa de cada proceso, donde veremos que su conformación difiere grandemente de una metodología en cascada (waterfall).
Una de las primeras características que son notables es el hecho que no existe una jerarquía formal dentro del equipo, lo que se origina al atender dos de los principios de SCRM (que veremos más a detalle en la siguiente entrega):
Un equipo de SCRUM se genera y funciona dentro de una organización que típicamente tiene una estructura jerárquica; muy probablemente varios de sus integrantes, al ser un equipo multidisiplinario, tengan jefes diferentes y que, por definición, les rinden cuentas, pero dentro del equipo de trabajo para el proyecto, todos deben ser vistos como iguales, ya que este es un requisito para lograr que internamente se organicen y logren una colaboración efectiva.
De igual forma, se debe especificar que este personal estará asignado exclusivamente al proyecto y no puede atender otros trabajos o solicitudes de la organización, para poder lograr un paso sostenible de los entregables y que la calidad de los estos no se vea afectada.
Resumiendo, todos los roles tienen el mismo peso al momento de integrarse en el equipo.
Scrum Won't Resolve Issues that Need to be Handled at the Management Level.
Lo primero que debemos ver es que tenemos un conjunto definido y muy específico de los roles que componen el equipo y son mandatorios, es decir, deben estar presentes a lo largo de todo el proyecto, hasta su conclusión.
Fuente: Desire (https://desire.webs.uvigo.es/)
Scrum Master, el nombre puede implicar cierta superioridad sobre el resto de los integrantes, pero lejos de esto, se le considera un líder servicial (servant leader), ya que su función no es organizar el trabajo, como sería el de un project manager tradicional, sino que se encarga de conducir las reuniones periódicas, identificar los problemas internos y externos que bloquean el trabajo y eliminarlos, evangelizar y dar a conocer la metodología dentro y fuera del equipo y coordinar las presentaciones de los entregables para la aceptación de los mismos. En resumen, es un gestor interno que además puede tener un rol adicional dentro del grupo (por ejemplo, un desarrollador o arquitecto de soluciones), que tiene un rango similar al resto de los integrantes del equipo.
Un punto importante es que un administrador de proyectos, en caso de caer en este rol, puede sentirse disminuido debido a que no tiene una posición de autoridad, por lo que es necesario que tenga muy claro la forma de trabajar con esta metodología.
Product Owner, considerado “la voz del cliente”, es quien tiene el conocimiento de las necesidades de los usuarios del producto, ayuda a generar el Product Backlog y la jerarquización de las tareas para el proceso de creación de entregables; a diferencia del Scrum Master, cuya actividad es principalmente al interior del equipo, este tiene además el contacto directo con los usuarios objetivo y vigila que el trabajo este alineado con la visión final, además de revisar que las pruebas del producto sean congruentes con las historias de usuario. Durante las reuniones diarias, no puede participar, pero es requisito que esté presente para conocer los avances y stoppers de cada etapa.
Un punto importante es que el Scrum Master y el Product Owner no pueden ser la misma persona.
El equipo Scrum, es el grupo interdisciplinario, compuesto de entre 6 y 10 personas, encargado de generar los entregables del proyecto, atendiendo las necesidades contenidas en las historias de usuario y las especificaciones del Product Owner. Este equipo debe tener la libertad de organizarse de acuerdo a su experiencia y conocimientos para poder generar los entregables conforme a lo solicitado.
Una característica importante es que el equipo se retroalimenta a sí mismo y genera o mejora las habilidades de sus integrantes a través de un esquema de entrenamiento interno, que eleva la calidad y la velocidad de entrega.
Atendiendo a la idea de Transparencia que también forma parte del esquema de Scrum, existen otros roles no esenciales pero que pueden intervenir de forma indirecta e incluso, estar presentes durante las reuniones de avance, pero no son responsables de la conclusión del proyecto. Estos roles se deben considerar dentro del proyecto.
Como pudimos ver, los equipos de Scrum tienen una composición y dinámica muy particular, que está orientada a mantener un paso que, en la teoría, puede ser de forma indefinida y sin que se vea afectada la calidad, pero es requisito que se mantenga como una unidad aislada de las distracciones del resto de la organización, para que se garanticen los entregables.
Con estos adelantos, podemos revisar próximamente los principios de Scrum.
Tu opinión