Qué es un equipo Scrum

A diferencia de los demás actores, que son unipersonales, el equipo Scrum es la unión de varios miembros. Su objetivo principal es que la visión del producto se concrete mediante el proceso de desarrollo. El equipo no tiene que ser homogéneo en cuanto a capacidades y habilidades, de hecho, es muy posible que no sea así, ya que para el desarrollo de un producto son necesarios varias área de conocimiento. Si bien es cierto que para el caso más reconocido, el de desarrollo de software, se tiene a pensar que todas las personas son desarrolladoras, es evidente que existirán roles diferenciados entre ellas, por ejemplo, desarrolladores de backend y frontend, e incluso, se puede incluir a otros profesionales como diseñadores.

Un proyecto puede tener varios equipos. Los equipos suelen tener entre 6 y 9 personas, por lo que a veces se hace necesario incrementar el numero de equipos para mantener un ritmo de desarrollo normal y mantener un ambiente de trabajo motivador.

Funciones y características de un equipo Scrum

La función principal de un equipo Scrum es la de desarrollar un producto en cada sprint listo para ser distribuido y de calidad, no solo para el cliente sino para el propio equipo de desarrollo. Esto se traduce en un producto sin deuda técnica, ya que no hay que olvidar que el ciclo de desarrollo es recursivo y todas aquellas cosas que no se hacen bien terminarán pagándose en ciclos sucesivos tarde o temprano.

Si por algo se define Scrum es por las relaciones en el equipo de desarrollo. Cuidar estar relaciones, y fomentar un espíritu colectivo sin duda generará un ambiente motivador y por lo tanto, un mejor desempeño del equipo durante el desarrollo. Además de fomentar unas buenas relaciones en el equipo, todos los actores deben entender que éste se debe regular sólo, bajo la tesis de que nadie como el equipo conoce cómo hacer mejor su trabajo. De esta forma se fomenta la independencia de sus miembros y permite que se generen sinergias en el equipo.

El equipo es un conjunto de personas que trabajan como una sola. Los éxitos y fracasos son colectivos, y se debe evitar a toda costa el señalamiento de un individuo concreto, mucho menos si es para hacerle una crítica destructiva.

Otra de las características claves del equipo Scrum es la multidisciplinariedad de los miembros del equipo. Un integrante del equipo puede tener competencias muy avanzadas en un ámbito de desarrollo concreto, pero conviene que no se acomode. Es posible que para algunas tareas el equipo recurra a la persona más experta para su implementación, pero puede que sea incluso más interesante que otro miembro del equipo se encargue de ella bajo la supervisión de su compañero más experto y que puede estar realizando tarea principal que le permita disponer de tiempo para transmitir sus conocimientos. Lo importante es que el equipo sea rotativo de forma que nadie se haga indispensable y todos los integrantes tengan al cabo de un periodo de tiempo una experiencia en varios campos que les den una visión global de todos los proyectos a los que harán frente en un futuro. Nadie por tanto, debe acomodarse en un rol. Diseñadores, desarrolladores de back y front… todos y todas deben ser capaces de salir de su zona de confort y mediante el apoyo mutuo, llegar a un buen resultado, con la satisfacción de haber aprendido algo nuevo y haber superado un pequeño reto profesional y personal. Además, esta rotación genera un mayor conocimiento del equipo por parte de cada individuo, favorece la comunicación e incrementa el sentimiento de pertenencia al grupo, que en consecuencia mejora la satisfacción y productividad.

De la misma forma que el Product Owner y el Scrum Master tienen rasgos psicosociales deseables, los miembros del equipo Scrum también deberían de disponer de habilidades que les permitan trabajar en equipo, tales como la empatía y la asertividad. Puede que existan personas con mas dificultades en este ámbito que otras por lo que el Scrum Master debería facilitar un entorno en el que se faciliten estas actitudes. De poco sirve un gurú poco comunicativo o que genere un ambiente (es muy conocida la soberbia de muchos grandes desarrolladores), ningún equipo Scrum podrá mejorar si no existe un alto grado de implicación con todos los actores del proyecto.

Dentro del equipo no existen jerarquías. Dan igual los conocimientos o la experiencia profesional. No existen líderes formales, nadie tiene más poder que nadie ni puede organizar a todo el equipo. Sin embargo, es inevitable que en cualquier grupo humano se generen liderazgos tácitos o informales, que suelen estar asociados a personas con carisma o recursos, en este caso, conocimientos. El manejo de los grupos Scrum requiere un alto grado de experiencia y no es fácil en determinadas circunstancias. Si la empresa no tiene interiorizada las ventajas de la metodología Scrum fácilmente puede caer en la tentación de volver a antiguos roles jerárquicos llevándose por delante todo el progreso conseguido y generando una dependencia que a futuro puede ser letal.

Interacción del equipo Scrum con el dueño de producto

El medio por el cual se comunican estos dos actores es principalmente el Backlog. El Backlog contiene tareas que son añadidas, eliminadas y modificadas por el Product Owner, pero es el equipo de desarrollo quien las implementa y las convierte en algo tangible.

A pesar de que el Product Owner es quien define las tareas y tiene la visión a futuro del desarrollo del producto, es el equipo de desarrollo quien tiene la última palabra de las tareas que se va a realizar en el sprint. Aunque el equipo negocie con todos los demás actores, siempre decide a qué se compromete y que objetivos se marcan en el sprint. Se puede pensar que el equipo se puede llegar a acomodar, asumiendo una carga de trabajo inferior a la que puede dar. Frente a esta idea, es necesario puntualizar dos cosas. La primera es que el equipo está compuesto de personas. Siempre es posible hacer más y trabajar durante más horas pero en última instancia lo que tendremos es un equipo quemado. Lo segundo es que a la larga sale más rentable gastar esfuerzos en crear las condiciones ambientales para que los trabajadores se motiven que gastar continuamente recursos y tiempo en el seguimiento y presión al equipo de trabajo.

El equipo puede comunicarse con el Product Owner durante el sprint en casos concretos. Por ejemplo puede que el equipo se encuentre con un problema que requiera una reestimación del tiempo o del impacto en otras tareas. En ese caso, debe comunicarse la eventualidad rápidamente con el dueño del producto y realizar las adaptaciones correspondientes al Backlog.

Interacción del equipo Scrum con el Scrum Master

Durante todo el proyecto, tanto el Scrum Master como el equipo de desarrollo están estrechamente ligados. De hecho, se puede dar el caso de que el Scrum Master forme parte del equipo de desarrollo e incluso de que sea un rol rotativo. La relación de camaradería es esencial entre estos actores. EL Scrum Master vela por los intereses del equipo, pero también les exige y les motiva para que den lo mejor de si. Es por tanto un líder para el equipo y la primera persona a la que debe acudir un miembro del equipo cuando necesita algo o tiene algún problema ya que conoce tanto al equipo como al proyecto.

Dentro del equipo también se puede dar el caso de que existan conflictos. En este caso, el Scrum Master debe ser quien facilite una solución, mediando en dicho conflicto. Se presupone una voluntad de todas las partes para llegar al entendimiento, de otra forma, se habrá llegado a un punto en el que el trabajo del Scrum Master podría verse en entredicho.

El Scrum Master no organiza ni dirige ni tiene un rol ejecutivo en el equipo. Ni siquiera está en un nivel jerárquico superior. Únicamente facilita el trabajo del equipo de desarrollo. Para ello debe tener a disposición recursos tanto internos como externos a la empresa, como pueden ser formaciones u otros profesionales expertos que puedan echar un cable eventualmente para casos concretos.

El equipo Scrum durante el Scrum diario

El Scrum diario es el ritual en el que los miembros del equipo, moderados por el Scrum Master, deben responder a las siguientes preguntas:

• “¿Que hice o conseguí ayer?”
• “¿Que voy a hacer hoy?”
• “¿Que dificultades estoy teniendo?”.

En caso de que algún miembro del equipo quede sin una tarea asignada, debe centrarse en cuestiones tangenciales al proyecto o puede requerir al Scrum Master que le asesore sobre algún punto que requiera una mayor atención en el presente o en el futuro. Lo importante es que ninguna persona esté sin hacer nada.

El tiempo de la reunión debe ser estipulado de antemano siendo lo canónico 15 minutos, por lo que los desarrolladores del producto tendrán aproximadamente entre 1 y 2 minutos para responder estas preguntas. Es indispensable que todo el mundo esté atento a la reunión. Los desarrolladores no se dirigen al Scrum Master, sino a sus compañeros, y estos deben atender para comprender el momento del desarrollo en el que están e incluso, poder ayudar a un compañero en una de las dificultades que haya manifestado y para las que se tenga una solución.

Es muy recomendable que los miembros del equipo lleven un pequeño guión a la reunión a fin de ceñirse a las preguntas, reflexionar sobre ellas, ajustarse al tiempo y mejorar su exposición.

El equipo Scrum durante la planificación del Sprint

Para la planificación del sprint, todos los miembros del equipo deberían familiarizarse previamente con las tareas que se encuentran en el Backlog, a fin de poder hacer una estimación del esfuerzo necesario en realizar cada tarea, que se podrá discutir en grupo antes incluso de la planificación del propio sprint en la reunión.

Una vez estimada la dificultad y esfuerzos requeridos para cada tarea, el equipo deberá elegir aquellas que van a formar parte del Backlog del sprint. El Product Owner podrá sugerir y alentar al equipo para que implementen según qué tareas pero la ultima palabra la tienen los desarrolladores, que se presuponen expertos en este área y son conscientes de las dificultades que pueden tener según qué tareas y cual es el mejor momento para realizarlas. El equipo debe ser fiel al plazo de entrega del sprint. Es de vital importancia que no existan retrasos en la entrega de la nueva versión ni que el equipo se sobrecargue de trabajo. La clave está en la exigencia y la motivación, y nunca en la imposición.

Si no se logra un consenso en la implementación o en las tareas a elegir para el sprint, el Scrum Master, que detenta el rol de mediador, debe velar por solucionar el conflicto.

Una buena forma de acercar las estimaciones a la realidad del tiempo de desarrollo es dividir las tareas complejas en otras de no más de un día de duración. Está demostrado que las tareas más sencillas (o con menos lineas de código) tienen un índice de error mucho menor que las tareas más complejas¹. Dividir es vencer.

El equipo Scrum durante la revisión del Sprint

La revisión del sprint es el momento en el que se evalúa dentro del equipo los avances conseguidos en el último sprint. Todo el equipo debe estar presente a fin de poder demostrar el trabajo de cada uno de sus miembros en el último sprint.

Es importante que el individuo que haya implantado la nueva funcionalidad que se quiere mostrar, sea quien la presente pues no hay nadie mejor que él o ella para hacer ver todas las aristas de la tarea implementada. El objetivo de esta reunión es por tanto dar a conocer a todo el equipo el nuevo estado del producto y terminar conociendo cuál va a ser el camino a futuro que pretende desarrollar el Product Owner.

El equipo Scrum durante la retrospectiva

La retrospectiva es un momento de análisis de las cosas que se hicieron bien y las que fueron mal. Cada miembro debe hablar de lo que funcionó y no funcionó en el equipo. Siempre se debe mantener un tono asertivo, señalando los problemas y no a los individuos. Es imprescindible por tanto la madurez de todos los miembros del equipo para diferenciar un ataque personal de una apreciación profesional y ser lo suficientemente humildes para asumir los errores propios y trabajar en ellos en un futuro. Al fin y al cabo, esta fase del desarrollo sirve para crecer como equipo.

A la hora de identificar problemas hemos dicho que es necesaria la asertividad, así como otros atributos. Aprender ha hacer críticas viene de serie. Solemos centrarnos en aspectos generales e impresiones, y pocas veces nos fijamos en las causas o el contexto en el que se produjeron los fallos. Si existió un error, no necesariamente se debe a la incompetencia de un miembro del equipo, o a la falta de habilidades. Puede que una tarea no estuviese bien explicada en el Backlog, pasase desapercibida en la preparación del sprint y en medio de este, surgieran problemas, por poner un ejemplo. De cualquier forma, lo importante es darse cuenta de que estos errores, bien analizados y comentados con transparencia harán al equipo mucho más fuerte e independiente en el futuro.

————————-

¹Estimating Software Cost. McGrawHill 1998 Casper Jones