La metodología Scrum es un tipo de metodología Agile enfocada a gestionar proyectos de desarrollo software con el objetivo de maximizar el retorno de la inversión de una empresa sobre un nuevo o existente producto. Sería incorrecto comparar entre una metodología Scrum y una metodología Agile ya que Agile es una mentalidad para gestionar proyectos y Scrum es un marco específico con unas reglas, roles y comportamientos esperados. En este artículo nos vamos a centrar en los roles que forman parte de esta metodología y sus funciones en cada situación dentro de una Sprint. Si no conoces sus bases, puedes ver qué es una Sprint y sus fases en este enlace.

Roles principales en Scrum

A continuación vamos a mencionar los roles mínimos que deberían existir en un proyecto de desarrollo de software ejecutado con la metodología Scrum. Asimismo, explicaremos las responsabilidades principales que debe asumir cada rol y cuándo debe intervenir, o bien, cuándo le corresponde un rol de oyente.

Product Owner

Todo proyecto empieza con este rol. El Product Owner es el encargado de aterrizar la idea de proyecto en tareas realizables. A veces, el mismo Product Owner es quien tiene la idea de proyecto y también la desglosa en partes para que el equipo de desarrollo tenga más facilidad a la hora de proyectar una estimación sobre cada tarea.

No es necesario que el Product Owner tenga todo el proyecto desglosado en tareas, a partir de ahora lo llamaremos requisitos, antes de empezar el desarrollo. Sí es necesario tener una visión general a 6 meses vista de lo que se quiere pero no de forma detallada. Con tener uno o dos meses de detalle sería suficiente para empezar un desarrollo de software con la metodología Scrum.

Aquí detallamos las principales responsabilidades que debe de tener un Product Owner:

• Definición del producto
• Encargado de decidir los cambios a medio plazo del producto
• Detallar cada requisito tanto de forma funcional como en diseño
• Priorizar los requisitos que se deben desarrollar próximamente
• Testear los requisitos entregados
• Aprobar los requisitos que van a moverse a un entorno productivo
• Comunicación con sus Stakeholders
• Medir el retorno de inversión de los desarrollos que se van realizando

Mencionando el concepto “medir el retorno de inversión”, es primordial tener controlado esta faceta ya que el principal objetivo de una metodología Scrum es llegar a tener un producto funcional y de calidad en un menor tiempo posible. Cada desarrollo se debe medir con el fin de entender si dicho desarrollo aumenta el retorno en el aplicativo final.

Por ejemplo, el Product Owner tiene una web de noticias y analiza que están teniendo una caída en el tiempo medio de visita por usuario en la página principal, lo cual repercute en los ingresos. Para aumentar ese tiempo medio, lo que hace es añadir una pequeña descripción debajo de cada titular con el objetivo de que el usuario se quede leyendo y así subir su duración media. Para saber si dicha mejora va a aumentar el retorno o no, hay que medir la nueva duración media respecto a la anterior. Si funciona, seguirá añadiendo mejoras en esa línea, si no, deberá cambiar el rumbo con otra idea.

Realmente el objetivo no es que todo se desarrolle en tiempo récord, pero sí que se llegue a una solución óptima lo antes posible gracias a la agilidad de cambio que permiten dichas metodologías.

Scrum Master

Es el orquestador de todo el proyecto, el director de la batuta que controla el trabajo de los demás. El principal objetivo del Scrum Master es que el transcurso del proyecto fluya de la mejor forma posible. Hay muchas personas que creen que este rol debe encargarse de que no haya problemas o interferencias en el transcurso, pero no es así. Los problemas y los imprevistos son inevitables, aunque tengas el mejor equipo del mundo. Lo que sí se debe encargar es de solucionar dichos imprevistos cuando surjan y lo antes posible.

Debe de ser una persona imparcial. A qué me refiero con esto: normalmente una empresa no tiene un equipo de Scrum Masters, sino que alguien debe de asumir ese rol, ya sea de la parte de negocio o bien de la parte de IT. Por lo general suele ser alguien de IT debido a sus capacidades técnicas y organizativas con las herramientas tecnológicas. Supongamos que sea así, el equipo de desarrollo también es de IT, por tanto, hay que ir con cuidado a la hora de tomar ciertas decisiones que favorezcan siempre a según qué parte. Dar la razón siempre a la parte que mejor te caiga es un error común en estos roles ya que genera desconfianza por parte del Product Owner.

Aquí detallamos las responsabilidades principales que debe asumir un Scrum Master:

• Revisar que los requisitos tengan la información necesaria
• Programar todas las reuniones de la Sprint
• Desbloquear los impedimentos que surjan
• Acordar y comunicar los requisitos que vayan a entrar en cada Sprint
• Tomar decisiones sobre requisitos que no se hayan cumplido
• Tiene la última palabra cuando haya un desacuerdo respecto a algún requisito
• Medir la ejecución de una Sprint
• Promover la comunicación entre los distintos equipos

No hay un indicador que pueda medir exclusivamente que un Scrum Master está haciendo bien su trabajo, ya que también dependen de otros equipos. Justo por esto le interesa que los demás equipos lo hagan bien y se encarga de medir el rendimiento de ellos. Un ejemplo sería ver cómo se van entregando requisitos a medida que pasan los días dentro de una Sprint. Este indicador mide si el equipo de desarrollo está terminando los requisitos a tiempo para finalizar correctamente la Sprint o lleva cierta desviación.

Scrum Team

Es el equipo de desarrollo. Normalmente está formado por más de una persona y está compuesto por distintos roles técnicos. Es muy recomendable que haya un líder técnico, quien organice las tareas a desarrollar por cada miembro y sea quién tenga la última palabra para decidir la solución técnica sobretodo en desarrollos complejos.

En este equipo sí que todos los miembros forman parte del equipo de IT y deben dominar las tecnologías que requiere el proyecto. Por lo general estas personas suelen trabajar la jornada entera para el mismo proyecto, mientras que los otros roles no tienen por qué dedicar todo su tiempo laboral a un mismo proyecto, no hay tanta carga de trabajo.

Seguidamente detallamos las responsabilidades que tiene el Scrum Team:

• Proveer de estimaciones en tiempo y complejidad para cada requisito detallado
• Proponer y diseñar la solución técnica que mejor se adecúe a cada requisito
• Desarrollar los requisitos incluídos en cada Sprint
• Cumplir, en la medida de lo posible, con las estimaciones que han dado

Es el rol que menos responsabilidades tiene pero que más horas dedica al proyecto y, por tanto, el éxito del proyecto pasa por sus manos.

Conclusiones

Hay opiniones distintas sobre qué factor es el que hace que un equipo entero funcione mejor o peor en una metodología Scrum. Personalmente pienso que la clave está en la cohesión del equipo, y no hablo sólo del equipo de desarrollo, sino de todo el conjunto.

Una metodología Agile requiere de mucha comunicación e interacción tanto en distintas reuniones como también mediante herramientas de chat. Si dos personas no se llevan bien, es muy difícil que luego la comunicación entre ellos sea la más adecuada. Se ha demostrado que con equipos cohesionados el rendimiento es mayor e incluso llegan a sacar más requisitos durante el mismo tiempo que otros equipos no tan cohesionados. Incluso las figuras de Scrum Coach existen para mejorar la comunicación entre ellos y potenciar esta parte.