En el mundo de Scrum, no solo los roles primarios como el Scrum Master, el Dueño del Producto y el Equipo de Desarrollo son esenciales. Existen los roles secundarios que, aunque no son indispensables, pueden influir en el desarrollo y dirección del proyecto. Estos roles secundarios no tienen una definición formal dentro del equipo del proyecto, pero su existencia puede ser valiosa para comprender el entorno más amplio en el que opera el equipo de Scrum.
Los roles secundarios no son responsables del éxito del proyecto, pero pueden ofrecer perspectivas, recursos y apoyo que pueden ser invaluables en ciertas circunstancias. Por ejemplo, podrían ser partes interesadas, usuarios finales, especialistas en un dominio específico o incluso otros equipos dentro de una organización que tienen interacciones ocasionales con el equipo de Scrum.
A pesar de que estos roles no tienen tareas o responsabilidades formales en el marco de Scrum, pueden influir en las decisiones del equipo o contribuir con comentarios e ideas. Dado que el Scrum valora la comunicación y colaboración entre los miembros del equipo y las partes interesadas, los roles secundarios pueden tener un impacto indirecto en el resultado del proyecto.
Es esencial que los equipos de Scrum reconozcan y entiendan estos roles secundarios. Si bien no son esenciales para la ejecución diaria del proyecto, podrían ser vitales para el éxito a largo plazo, especialmente si ofrecen recursos o experiencia que no está disponible dentro del equipo de Scrum.
Finalmente, es vital considerar a los roles secundarios en cualquier proyecto de Scrum para garantizar una visión holística del entorno del proyecto y maximizar el potencial de éxito al aprovechar todos los recursos disponibles, formales e informales.
Los roles secundarios en Scrum son aquellos individuos o grupos que, aunque no tienen responsabilidades directas en el proyecto, pueden interactuar con el equipo. Estos roles se reconocen y se toman en cuenta a lo largo de la duración del proyecto, aunque no tienen un conjunto específico de actividades ni un momento específico para intervenir. Generalmente, interactúan con el equipo según la necesidad del proyecto y las circunstancias, y no requieren herramientas específicas para su función.
Algunos ejemplos son los siguientes:
- Un especialista en seguridad informática que es consultado ocasionalmente por el equipo de Scrum para garantizar que el producto cumpla con los estándares de seguridad.
- Un representante de ventas que proporciona feedback sobre las características del producto basado en las opiniones de los clientes.
- Un equipo de soporte técnico que comparte información sobre problemas comunes que enfrentan los usuarios y que podrían requerir soluciones en futuras sprints.
- Un grupo de usuarios finales que son invitados a pruebas de usabilidad para proporcionar feedback directo al equipo de Scrum.
- Un arquitecto de soluciones que ofrece su perspectiva sobre la dirección técnica del producto sin ser parte del equipo principal.
