Fundamentos de Scrum Framework: los Desarrolladores

Este artículo forma parte de una serie en la que revisamos los fundamentos de Scrum complementados con infografías que los explican. Otros artículos: Sprint, Planificación, Daily, Review, Retrospectiva, Product Owner y Scrum Master.

Autores: Alonso Álvarez y Patricia Parreira. 

El equipo Scrum es una “unidad cohesionada de profesionales” donde no hay jerarquías o sub-equipos, pero sí “responsabilidades” (accountabilities) que cubren funciones básicas. La Guía Scrum en su última edición define tres:

• Construcción del producto con calidad y excelencia por parte de los Desarrolladores.
• La maximización del valor del producto entregado, el objetivo del Product Owner.
• Optimizar el flujo de trabajo con la aplicación del marco de trabajo Scrum, por el Scrum Master.

Aunque Scrum nació en el mundo del desarrollo software, hoy se utiliza en todo tipo de actividades: Marketing, diseño de producto, Recursos Humanos, incluso hay un Scrum para educación.

El último vestigio que queda de su origen es el nombre de esta responsabilidad: Desarrolladores o Developers, que engloba a la mayor parte de las personas que forman parte del equipo Scrum y que son quienes “se comprometen a crear cualquier aspecto de un Incremento útil (funcional) en cada Sprint”. Dicho de otro modo: quien hace el trabajo que aporta valor al cliente.

Este grupo de personas recibía antes la denominación de “equipo de desarrollo” pero era una contradicción con la idea de evitar jerarquías o subequipos. Ahora no hay más equipo que el equipo Scrum, y dentro de él, personas con distintas responsabilidades.

Los desarrolladores cuentan con las capacidades necesarias para desarrollar el trabajo dentro de un dominio concreto de conocimiento, evitando al máximo dependencias externas.

Es por eso que se dice que el equipo Scrum (Desarrolladores, SM y PO) es multifuncional, aunque al mismo tiempo deba ser pequeño, con un máximo de unas 10 personas. Un equipo pequeño facilita la comunicación y se ha demostrado repetidas veces que es más productivo que uno grande. En un equipo mayor acabarían apareciendo subdivisiones de forma natural.

Para que el equipo Scrum sea verdaderamente eficaz, es necesario que, además de pequeño, esté alineado con unos mismos objetivos y evitar duplicidades en las responsabilidades específicas de PO y SM.

Responsabilidades de los Desarrolladores

La división antigua del trabajo nacida a principios del siglo XX con Taylor establecía que unas personas –managers– pensaban, y otras -trabajadores- ejecutaban. Ese sistema es un enorme desperdicio que desprecia las capacidades de las personas que llevan a cabo el trabajo, lo que es especialmente grave en el mundo del trabajo intelectual.

Por ello, Scrum, y todas las distintas aproximaciones ágiles, asumen que las personas son autónomas, responsables y capaces de tomar decisiones y contribuir decisivamente al trabajo sin tener que esperar a que sean otros quienes les digan qué tienen que hacer y cómo.

En el caso de los Desarrolladores, esto se manifiesta en una serie de responsabilidades muy concretas según la Guía Scrum:

• “Crear un plan para el Sprint, el Sprint Backlog”. Es decir, los Desarrolladores tienen un papel muy destacado durante el evento de Planificación, participando y tomando decisiones de cara a sus , y definiendo -siempre de acuerdo con el Product Owner- el alcance del Sprint, que viene dado por su backlog.

Quienes tienen que desarrollar un trabajo son las personas más indicadas para estimar el alcance, esfuerzo y dificultades para llevarlo a cabo: por eso, los Desarrolladores son quienes están en mejor posición para determinar qué cantidad de trabajo puede completarse en un periodo de tiempo determinado. Se acaba así la idea de que la estimación la fija unilateralmente una persona por su posición jerárquica o conocimiento experto: estima el trabajo quien lo tiene que hacer.

• “Inculcar la calidad adhiriéndose a una definición de hecho”. El DoD o “Definition of Done” es un instrumento básico para gestionar la calidad ya que establece, bajo la forma de una checklist, las condiciones que determinan si un trabajo se puede considerar o no completado. El DoD puede estar estandarizado por la organización, pero, si no fuera así el equipo deber crear un DoD adecuado para su producto.
• “Adaptar su plan cada día hacia el Objetivo Sprint”, lo que se lleva a cabo por medio del evento de Daily Scrum o reunión diaria. Los Desarrolladores realizan una actividad continuada de Inspección y Adaptación (dos de los pilares de Scrum) para hacer todo lo posible por alcanzar el objetivo marcado durante la planificación. Por ese motivo, la Daily es un evento de y para los Desarrolladores, y hay que evitar que se convierta en una forma de reporte o de microgestión, en lugar de una herramienta para alcanzar los objetivos del equipo.
• “Responsabilizarse mutuamente como profesionales”. Una idea frecuente en los marcos y prácticas ágiles es la de propiedad compartida del producto en el que se está trabajando, lo que implica también una responsabilidad compartida. De esta forma, el trabajo no lo hace una u otra persona, si no que se considera que es cosa de todo el equipo. Y lo mismo ocurre cuando algo falla o no es como se esperaba: todo el equipo se preocupa de solucionarlo.

Los Desarrolladores y los eventos Scrum

Como parte del equipo Scrum, los Desarrolladores participan en todos los eventos, pero es que además tienen un papel especialmente relevante en dos de ellos:

• En la Planificación, donde tienen la especial responsabilidad de elaborar el plan a partir de estimar el contenido del nuevo incremento de producto.
• La Daily, que, como hemos dicho, es un evento estrictamente para que los Desarrolladores puedan inspeccionar el progreso y hacer adaptaciones en el plan si fuera necesario. Las otras dos responsabilidades pueden ser bienvenidas a este evento, pero ante todo la Daily se hace por y para los Desarrolladores.

Los Desarrolladores y las demás responsabilidades

Los Desarrolladores no están supeditados a SM y PO, en el equipo Scrum no hay jerarquías, aunque pueda haber distintas funciones.

En principio nada impide que una persona pueda compatibilizar más de una responsabilidad, aunque hay combinaciones que desaconseja el sentido común (no se puede ser a la vez PO y SM, ya que, por ejemplo, de forma natural el PO procurará conseguir un incremento de producto mayor, mientras el SM debe proteger al equipo y mantener un ritmo sostenible de trabajo), o la dedicación (para un o una PO es complicado hacer otras cosas).

De la misma forma, hay ciertas atribuciones tradicionalmente asignadas a SM que pueden distribuirse entre los Desarrolladores: por ejemplo, la Guía Scrum no dice que tenga que ser forzosamente el SM quien facilite las reuniones.

De la misma forma, tampoco dice la Guía que estas responsabilidades no puedan cambiar de persona dentro de un mismo equipo Scrum.

A fin de cuentas, todas las personas de un equipo Scrum tienen una responsabilidad compartida para sacar adelante su producto, servicio o simplemente trabajo que van más allá del nombre o función que ejerzan.

Scrum no debería servir de excusa para introducir o reformular jerarquías: el propósito de Scrum es “generar valor a través de soluciones adaptables para problemas complejos”. Todo lo demás es adorno, distracción o simplemente estorbo.

Descargar Infografía completa

¿Quieres conocer más prácticas Scrum?

Te recomendamos la formación “Agile Fundamentals”, un curso de 24h para empezar a aprender los conocimiento y habilidades de Scrum y Kanban, acreditado por ICAgile.

IR AL CURSO Agile fundamentals