Mitos y realidades de las responsabilidades de Scrum

El primer mito:Scrum no toma en cuenta roles de Analistas, Arquitectura, DBAs, Testers, Infraestructura, Seguridad.... ¡Mentiras! ¡Son todas mentiras! 
Hay 3 responsabilidades naturales de Scrum pero eson son los roles esenciales para la adopción de esta metodología, por supuesto que los demás roles forman parte de un proyecto hecho con Scrum, solo que la definición de su rol no se altera, simplemente se toma en cuenta como parte del equipo completo.

La primera realidad: Los roles naturales de Scrum son “Scrum Master”, “Product Owner” y “Scrum Developers”, el resto de los roles no se eliminan.

El Scrum Master es quien guía al equipo para cumplir las reglas, valores y procesos de Scrum y apoya en la reducción de impedimentos gestionando las actividades necesarias para librar de obstáculos el camino de su equipo. 
El Product Owner es quien representa la voz de los clientes/usuarios que usarán el software, su perspectiva es de negocio y su misión principal es que los involucrados entiendan la visión del proyecto y se priorice con base en las necesidades del negocio.

El equipo, conformado por Scrum developers, cuentan con los conocimiento técnicos necesarios para desarrollar el proyecto, lo hacen de forma conjunta contribuyendo de manera efectiva en un proyecto ágil ya que además cuentan con conocimientos suficientes sobre Scrum.

El segundo mito: La Certificación de Scrum Master es la más solicitada porque es la más importante 

Es un hecho que la certificación de Scrum Master es una de las más solicitadas, mi opinión es que es debido a que siendo quien guía a los equipos para cumplir las reglas y valores de Scrum al pensar en implantar este método, las empresas buscan quien ayude a hacerlo dentro de los proyectos ejecutando este rol, pero también percibo otra razón: La palabra “Master”.... y es que se escucha muy “cool”, nos podemos sentir que con ello seremos maestros del modelo y tal vez áreas reclutadoras que solicitan este perfil sin investigar mucho sobre los otros dos roles, pues se pueden ir por lo que les dice el nombre.

La segunda realidad: Lo efectivo es tomar la Certificación que esté más acorde a tu rol.

Como estrategia individual lo mejor es tomar la Certificación acorde a tu rol para lograr una alineación y especialización adecuada:

• Si tu conocimiento, experiencia y pasión están cerca de los requerimientos y del negocio, tu certificación es la de Product Owner.
• Si tu conocimiento, experiencia y pasión están cerca del desarrollo de software haciendo realidad las soluciones, tu certificación es la de Scrum Developer.
• Si tu conocimiento, experiencia y pasión están cerca del Liderazgo de proyectos para compartir el control, no para abusar del control, tu certificación es la de Scrum Master.

Como estrategia organizacional, es necesario capacitar a quienes vayan a iniciar en el camino de la agilidad y decidir si a todos se les comprometerá para que se certifiquen o si la certificación será opcional, esto último depende mucho de la cultura organizacional, del grado de compromiso que exista del personal y por supuesto, del presupuesto con el que se cuente.

El tercer mito: Teniendo Product Owners los analistas ya no tienen nada que hacer ¿lo crees?
Tomando en cuenta que el Product Owner es el representante de los clientes/usuarios, deciden lo que se va a desarrollar, priorizan las historias de usuario, explican funcionalidad requerida, validan entregas y participan en reuniones, inmediatamente se me viene a la mente a un Usuario clave de negocio, ese stakeholder o involucrado relevante que tiene todo el peso de las decisiones de negocio sobre el proyecto a desarrollar, si hay más usuarios con quienes se levanta requerimientos, el Product Owner siempre tendrá criterio de desempates y decisiones vitales, hasta aquí bien, definitivamente estamos hablando de un usuario de negocio hasta que nos enteramos que los Product Owners también son quienes redactan las historias de usuario, es lógico, si es lógico pero en la vida real es difícil que suceda, es decir que un usuario de negocio (que puede ser un(a) Director(a)) incluya en sus tareas la redacción de las historias de usuario y todo lo que ello conlleva. No dudo que haya quien lo haga, solo que en la cultura mexicana corporativa es difícil que suceda. Pero es en estos casos donde los Product Owners se pueden apoyar de los Analistas.

Dentro de la guía oficial de Scrum, se considera que el Product Owner puede delegar parte de sus funciones, lo único que por naturaleza no se delega al Analista es la Priorización, aunque los analistas podemos aportar en la vision para la priorizacion por valor, no somos los que tomamos directamente la decision.

La tercera realidad: Los Product Owners pueden trabajar con analistas
He visto que en algunas organizaciones, ante la problemática señalada anteriormente sobre la dificultad de que el Product Owner redacte sus propias historias, nombran como Product Owner a alguien del área de sistemas quien trabaja de codo a codo con el usuario de negocio, sin embargo, por experiencia en los proyectos que ejecutamos, prefiero recomendar el que al usuario clave de negocio se le deje el título de Product Owner y ejecute todas las actividades del rol con excepción del desarrollo de las historias de usuario y que para desarrollarlas se apoyen de un analista y ya el Product Owner se encargue de la validación de las historias.

Lo recomiendo así porque creo que es la forma en la que más se respeta el rol y más se apoya a la implantación del método. Claro que lo ideal sería respetar el rol al 100% pero mientras tanto, se que si continuamos evangelizando sobre la importancia del rol del Product Owner y capacitemos a nuestros usuarios en este rol, algún día se logrará, mientras tanto necesitamos adaptarnos.

Cuarto mito: Si no te dedicas a desarrollar software, no aplican los developers en tu equipo

La agilidad desde hace muchos años se ha abierto a otras industrias fuera del desarrollo de software y en más reciente actualización de la guía que fue en noviembre del 2020 ya quedó generalizada para uso en otros tipos de proyectos diferentes al desarrollo de software. Continúa la referencia a los "Developers" pero debe de ser tomado como los ejecutores del proyecto, es decir, los que hagan realidad la solución o el producto.

La cuarta realidad: Aunque la guía oficial de Scrum sea actualizado el Manifiesto ágil no se ha actualizado

Los valores y principios del manifiesto ágil siguen haciendo referencia al desarrollo de software, varios agilistas están del lado donde sugieren que se actualice, sin embargo, la falta de actualización no impidió que otras industrias adoptaran la agilidad.

Quinto mito: Habilita Scrum considerando solo lo que vienen en la guía oficial y con eso es suficiente

Scrum no tiene prácticas propias, es un marco de trabajo, no una métodología ni un método, es muy adaptable pero se tiene que trabajar en adaptarlo con las prácticas que al equipo le convengan hacer y que dichas prácticas sean compatibles con el Manifiesto ágil.

La quinta realidad: Scrum está incompleto, lo dice la guía (Referencia).

Es un excelente contenedor de prácticas pero no tiene prácticas propias, asi que si lo tratas de habilitar solo con lo que dice en la guía, estarás trabajando con algo incompleto y no te va a funcionar o aprovecharás muy poco el potencial de Scrum.

Conclusión

Cada responsabilidad en un proyecto es importante, cada uno hace la diferencia y aporta para el cumplimiento del objetivo, eso es con todos los roles, sean de Scrum o no.

Una persona con sentido de pertenencia de su rol y en sus responsabilidades, que ha recibido capacitación para ejercer sus actividades y que ha sido recibido inspiración para alcanzar los objetivos de proyectos y objetivos empresariales será una persona que llevará el éxito consigo, donde quiera que esté y bajo (casi) cualquier circunstancia.