El ciclo de producción en Scrum

El ciclo de producción en Scrum

por | Jul 17, 2018

Scrum es la adaptación de las metodologías ágiles más conocidas, y como tal es un framework que persigue los 12 principios del Manifiesto Ágil.

Siguiendo con estos principios, Scrum asume la entrega continuada del producto en verisiones estables periódicamente. Esto significa que el cliente verá como su producto incrementa su valor con cada nueva versión. Es un proceso por tanto iterativo, que se repite continuamente mientras el cliente necesite añadir nuevas funcionalidades al producto.

Para organizar el trabajo y no solo mejorar el producto, sino su proceso de elaboración, Scrum define un ciclo con una serie de hitos, fases y artefactos.

Los hitos son eventos, generalemente reuniones, que se producen a lo largo del ciclo de Scrum. Las fases son periodos de tiempo en los cuales el equipo Scrum se organiza con un fin especifico. Ambos están relacionados entre si mediante los artefactos de Scrum que son objetos creados para guiar el trabajo. Vamos a ver y relacionar todos ellos a través de la siguiente imagen que resume bastante adecuadamente todo el proceso:

El Product Backlog

El Product Backlog es el elemento central de Scrum. Es la pila de tareas que se deberán desarrollar para la consecucion del proyecto. Este artefacto está únicamente manejado por el Product Owner, que añadirá, eliminará y modificará tareas. Estas tareas deberán estar correctamente explicadas y con objetivos de terminación claros para que el equipo de desarrollo las evalúe y añada las que consideren que pueden desarrollarse en un sprint al propio Backlog del sprint. El Product Backlog contiene las tareas ordenadas en funcion de la prioridad que el Product Owner considere, pero eso no garantiza que vayan a ser implementadas en ese orden, sino que depende del equipo de desarrollo.

Usualmente las tareas del Product Backlog comienzan siendo más abstractas y se concretan a medida que avanza el tiempo, pues el cliente va teniendo más claro qué es lo que quiere y el Product Owner podrá detallar mejor los requerimientos.

Este artefacto es icónico de Scrum. Se suele representar y se recomienda que sea así, mediante una serie de columnas en las cuales se pegan papeles adhesivos con un código de colores en funcion de otros parámetros que se quieran representar: urgencia, complejidad, tipo de tarea, etc. Muchas veces se suele usar una pizarra, pero sirve cualquier superficie que sea visible y accesible para los miembros de Scrum. A diferencia del Backlog del sprint, no contiene diferentes columnas, ya que el estado de las tareas no varía hasta que se introduce en un sprint.

Refinamiento del Backlog

El objetivo de esta reunión es la de refinar las tareas del Backlog para su mejor comprensión durante el sprint. En este refinamiento el equipo de desarrollo se hace una idea de los recursos y el tiempo que le va a llevar completar cada una de ellas, estableciendo dependencias y recursos necesarios. Posteriormente pueden existir errores de estimación, pero la idea es que en esta fase se consiga acercar lo más posible la estimación a los recursos y tiempo reales del sprint, así como aclarar aquellas tareas del Backlog que no estén lo suficientemente claras.

La planificación del Sprint

La planificación del sprint es una reunion del Equipo Scrum (Product Owner, equipo de desarrollo y Scrum Master) en la que se van a elegir las tareas que van a formar parte del sprint. Estas tareas deben estar en el Backlog Product y pasarán a formar parte del Backlog del sprint. El Produt Owner se encarga de que todo el equipo entienda cual es la finalidad de cada tarea y en conjunto dirimen sobre la complejidad y el tiempo de desarrollo de cada una de ellas para llegar al estado de terminación de cada tarea. Aunque el Product Owner haya ordenado las tareas en el Product Backlog en función de prioridad, corresponde al equipo de desarrollo el elegir aquellas que formarán parte del siguiente Sprint.

El sprint Backlog

El Backlog del sprint es el icono por excelencia de Scrum. Consiste en una tabla con una serie de columnas por las cuales van pasando las tareas en función de su estado actual. Estas tareas son las escogidas durante la planificación del sprint. A medida que van cambiando de estado, van llegando a la ultima columna, que debe ser la de «terminado».

El Backlog del sprint tiene también una característica visible en las tareas y es que durante la planificación del sprint, a cada tarea incluída se le asignó un peso o un numero de horas para completarla. Esto nos sirve para manejar mejor los tiempos del sprint y tambien para hacer después una revisión y retrospectiva de cómo fue la estimación y conocer mejor al equipo, como veremos en sus respectivos hitos.

Es importante que cada tarea del sprint le corresponda a una y solo a una persona. Esto no quiere decir que no pueda pedir ayuda a sus compañeros pero

Existen muchas formas de organizar el Backlog del sprint, por ejemplo usando múltiples filas en función de la temática de la tarea, pero en cualquier caso, el común denominador es el flujo de las mismas. Al igual que el Product Backlog, el Backlog del sprint debe estar en un lugar accesible y visible para que los miembros del equipo sean capaces de ver el estado actual del sprint y poder manipular el estado de las tareas.

tablero scrum

Sprint

El sprint es la parte central del ciclo de desarrollo. Aquí el equipo de desarrollo se afana en introducir e implementar todas las tareas definidas enm el Backlog del sprint. La duracion es variable, en funcion del numero de tareas pero se recomienda que se mantenga constante en todo el proyecto y comprenda entre 2 y 4 semanas. Durante este periodo de tiempo el equipo trabaja a contrareloj y el Scrum Master procura evitar los impedimentos que puedan afectar al ritmo del trabajo. Es obvio que en esta fase el equipo puede estar sometido a estrés. No es deseable. El sprint debe ser exigente, pero no estresante para el equipo de desarrollo. La manifestacion de sintomas de estres derivan en frustración y falta de motivacion, por lo que para Scrum es de vital importancia atajarlos rápidamente. Por desgracia, el sprint no se puede detener y aunque es cierto que el estrés no es algo que pueda aparecer el el plazo de tiempo que sucede un sprint, fallos de estimación continuados que lleven al limite al equipo de desarrollo pueden ser fatales para el desempeño del equipo.

Durante el sprint el equipo de desarrollo tiene que ser autosuficiente y autorganizarse de manera que consiga llevar a cabo todas las tareas sin ayuda externa.

El Scrum diario

El Scrum diario es el ritual más definitorio de Scrum. Consiste en un a pequeña reunion a primera hora de la jornada laboral con una duracion no superior a los 15 minutos en los cuales los miembros del equipo responden a tres preguntas: qué hicieron ayer, qué harán hoy y qué dificultades se están encontrando.

El Scrum diario sirve para que todo el equipo conozca el estado actual del proyecto y des sprint, pudiendo identificar qué cosas van funcionando y cuáles no. El Scrum Master deberá tomar nota de las intervenciones de la reunión y facilitar la labor del equipo de desarrolo en aquellas cuestiones que no estén funcionando correctamente.

Es recomendable llevar esta reunión preparada de antemano para no excederse de los 15 minutos estipulados.

La revisión del sprint

La revisión del sprint es el siguiente hito tras el sprint. En esta reunión el Product Owner repasa las tareas definidas en el Backlog del Sprint y pide al equipo de desarrollo que se las muestre. El encargado de cada tarea da un paso al frente y demuestra que la tarea efectivamente se ha hecho y cómo. De esta manera todo el equipo llega a tener un conociemiento profundo de la tarea.

El cliente o Stakeholders pueden estar presentes en la demostración de la nueva version del producto.

La retrospectiva del sprint

Durante la retrospectiva del sprint se hace una evaluacion de todo el ciclo. El Scrum Master debe llevar la moderación de la reunión y los miembros del equipo deben comentar cuales han sido sus impresiones del ciclo, desde la planificacion hasta la revision del sprint.

El objetivo de esta reunión es la de generar un espacio seguro para la crítica constructiva entre los miembros del equipo Scrum. Es una reunión para sacar a la luz los problemas y darles una solución grupal. Todos los miembros deben asistir con la mente abierta y asumiendo sus errores, pero sin autocomplacencia, sino buscando mejorar el siguiente ciclo de Scrum mediante su superacion.

La retrospectiva es el punto de inflexion y es lo que marca que el equipo avance realmente en todos los aspectos para lo que se ha implantado Scrum en la empresa: independencia, autogestión y responsabilidad.

El Scrum Máster además deberá tomar nota de todos esos problemas que van surgiendo en cada retrospectiva para proponer soluciones a aquellas cuestiones que se repitan ciclo tras ciclo y abordarlos en las retrospectivas.

Y vuelta a empezar…

Scrum es un framework de mejora continua, no solo del producto sino del equipo. Una vez liberada la nueva versión, se debe volver a la fase de refinamiento del Backlog. Para este momento el Product Owner ya habrá colocado en el tablero del Backlog Product nuevas funcionalidades a ser implementadas y el equipo de desarrollo tendrá que volvera revisarlas, estimar el esfuerzo necesario y planificar el siguiente sprint.

 

El equipo de desarrollo

El equipo de desarrollo

por | Jul 17, 2018

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<sup>1</sup>. 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.

————————-

<sup>1</sup>Estimating Software Cost. McGrawHill 1998 Casper Jones

El Scrum Master

El Scrum Master

por | Jul 17, 2018

¿Que es un Scrum Master?

El Scrum Master conecta a todas las partes implicadas en el proyecto. Participa con todos los demás actores, coordinando las actividades y los flujos de comunicación. Muchas veces esta figura es malinterpretada porque se le asocia un rol de “jefe” o responsable del proyecto, pero no es así. El Scrum Master es el facilitador para que todo el equipo pueda trabajar cómodamente y superando las eventualidades que puedan surgir durante el desarrollo. En definitiva, no es el responsable del éxito o fracaso del producto, sino el encargado de mantener al equipo motivado y activo, además del responsable de que se siga la metodología Scrum en todo momento

Funciones y características del Scrum Master

Si bien hemos comentado qué es el Scrum Master y algunas de sus funciones, no sabemos qué características debe tener un profesional con este perfil, ni de qué forma debe interactuar con los demás actores. El Scrum Master pasa la mayor parte de su tiempo solucionando posibles inconvenientes del equipo de desarrollo, y eso implica que debe ser una persona abierta, empática y asertiva. Debe saber manejar eficientemente conflictos o mejor aún, atajarlos antes de que se manifiesten, yendo en la medida de lo posible un paso por delante de todos los demás actores. Ten en cuenta que en un sprint el tiempo es oro y es importante saber resolver eventualidades de una forma eficaz y eficiente. Si por ejemplo en un sprint hay una tarea dependiente de otra, el Scrum Master debe ser capaz de establecer prioridades manteniendo a todo el equipo activo, otorgando una mayor prioridad a la tarea de la que dependen.

Es crucial que el Scrum Master conozca a su equipo a fondo, tanto profesional como personalmente. Profesionalmente porque durante el desarrollo de un producto es evidente que existirán personas que necesitarán mayor seguimiento y apoyo que otras y personalmente porque es evidente que la productividad está estrechamente ligada a la comodidad de un empleado en su puesto de trabajo.

El Scrum Master, al no poseer un carácter jerárquico puede ser virtualmente cualquier persona con las características anteriormente descritas aunque evidentemente tendrá que tener unas nociones básicas del marco profesional en el que se desarrolla el proyecto (de poca ayuda nos servirá un Scrum Master en el desarrollo de una aplicación Android que no tenga conocimientos de programación o un full-stack developer en un equipo financiero). Por supuesto el Scrum Master tiene que tener interiorizado el framework de Scrum para poder implementarlo.

A pesar de que no existir una jerarquía tradicional, el Scrum Master debe ser un líder dentro del equipo. No debe imponer ni ordenar, pero debe destacar como la punta de lanza y el referente al que acudir con confianza.

Existen cuatro tipos de Scrum Master:

  • El Scum Master rotativo, asignado aleatoriamente después de la finalización de cada ciclo a una persona perteneciente al equipo. La ventaja es que favorece la implantación de Scrum y posee un amplio conocimiento personal y profesional de los desarrolladores. La desventaja es que no todas las personas tienen las características que hemos descrito anteriormente, sobre todo a nivel interpersonal.
  • El Scrum Master de tiempo parcial, el cual compagina su trabajo como desarrollador del equipo con su faceta de Scrum Master. Tiene las mismas ventajas que el Scrum Master rotativo y elimina la posibilidad de que la aleatoriedad señale como responsable a una persona no enteramente capacitada para este rol.
  • El Scrum Master a tiempo completo, el cual se dedica exclusivamente a este rol en un equipo, lo que permite una mayor especialización y fluidez en el desempeño en su tarea y es típico de pequeñas y medianas empresas.
  • El Scrum Master a tiempo completo y compartido se diferencia del anterior en que maneja varios proyectos simultáneamente siendo más frecuente por tanto en empresas grandes.

Interacción del Scrum Master con el equipo de desarrollo

En cada ciclo existen diferentes fases en las cual el Scrum Master se relaciona con diferentes actores. Posiblemente sea en el sprint cuando su tarea se vuelve más crucial, pues es el momento en el que debe sacar a la luz todas las cualidades resolutivas que se esperan de él. Como ya hemos dicho, el Scrum Master no es un jefe, no tiene capacidades ejecutivas sobre el equipo ni autoridad para tomar decisiones empresariales, lo tiene sentido ya que minaría su capacidad para generar espacios de comunicación abiertos y comportarse como un líder. Es un igual con el equipo de desarrollo y su única autoridad efectiva radica en la planificación de los rituales Scrum. En relación con el equipo, el Scum Master debe tener en cuenta que muchas veces más no es mejor. Hablamos de que puede existir la tentación por parte del equipo de desarrollo y otros actores de planificar un sprint con un número irreal de tareas. Un buen Scrum Master vela tanto por la seguridad del proyecto como por la integridad del equipo de desarrollo. De poco nos sirve un sprint ultra exigente si va a provocar que no se presten atención a los detalles, se incremente la deuda técnica (retrasando otros sprints) y genere burnout y frustración en el equipo. Hay que tener en cuanta que después de cada ciclo, viene otro y debemos afrontarlo con los desarrolladores lo más motivados posible. Unas estimaciones poco realistas en sprints sucesivos pueden ser letales para el equipo de desarrollo.

Interacción del Scrum Master con el Product Owner

El rol del dueño del producto en Scrum es, a diferencia de otros modelos de producción no ágiles, central para llegar al objetivo común, pues es parte activa durante la construcción/evolución del producto. El Product Owner es el encargado de transmitir las nuevas funcionalidades que aumentarán el valor del mismo mientras que el Scrum Master (junto con el equipo) son los encargados de seleccionar aquellas más relevantes para el siguiente ciclo de producción. El Scrum Master debe negociar con el dueño del producto los plazos y las características a implantar en el nuevo ciclo de producción, evitando la anteriormente mencionada sobrecarga en el siguiente sprint, haciéndole ver y orientándole en función de las capacidades del equipo, cuáles pueden ser las prioridades del mismo.

El Scrum Master en el Scrum diario

El Scrum Master es el encargado de que se cumpla el ritual de Scrum diario. Su papel es el de moderar las intervenciones y hacer que se cumplan los canónicos 15 minutos que debe durar la reunión. Y ojo, porque moderar no significa se el eje en torno al cual gira la reunión. De nuevo la palabra clave es la facilitación. El Scrum diario no se hace para informar al Scrum Master sobre los avances y problemáticas que encuentra cada desarrollador cada día (eso puede hacerse en cualquier momento de la jornada laboral), sino para informar al resto del equipo de ellos. De hecho, la reunión en equipos que hayan interiorizado Scrum puede perfectamente realizarse eventualmente sin la presencia del Scrum Master, aunque su asistencia es muy útil, pues es el mejor momento para analizar las relaciones entre los miembros y enterarse del estado real del proyecto.

El Scrum Master en la planificación del Sprint

El Scrum Master es el encargado de planificar con el equipo de desarrollo y el dueño del producto el siguiente Sprint. Como ya hemos dicho, el Scrum Master tiene que ser capaz de analizar los recursos y por tanto la carga óptima de trabajo que puede mantener el equipo de desarrollo. Al mismo tiempo debe negociar con el dueño del producto las nuevas funcionalidades del software que se van a añadir en función de la carga de trabajo capaz de mantener el equipo de desarrollo. Es posible y normal que el dueño del producto quiera tener el mayor numero de funcionalidades implementadas en el menor tiempo posible, sin embargo, el Scrum Master debe poder comunicarle de forma efectiva las capacidades del equipo del desarrollo, manteniendo un ritmo de trabajo adecuado, ni endiablado ni cómodo, sino desafiante pero asequible.

El Scrum Master durante la revisión del sprint

A diferencia de otros rituales de Scrum, en la retrospectiva, el Scrum Master se hace a un lado para dar el control de la reunión al dueño del producto que se encarga de explicar cómo afecta cada tarea completada del Backlog del sprint en la nueva versión del producto. El Scrum Master se debería limitar a mantener los tiempos y facilitar un marco a la reunión, facilitando los materiales necesarios para su desarrollo a ser posible antes de su celebración. Por ejemplo, un burndown chart o un pequeño resumen del ultimo sprint pueden ayudar a guiar la reunión, además de tener una perspectiva general y actualizada del proyecto.

El Scrum Master durante la retrospectiva

Durante la retrospectiva el Scrum Master reúne al equipo de desarrollo e inicia un proceso de autoevaluación de todo el ciclo. La función principal del Scrum Master en el equipo de desarrollo es la de generar un espacio seguro para la crítica constructiva y el reforzamiento del espíritu de grupo. Debe procurar que se expongan aquellas cosas que no funcionaron bien, y a ser posible, que sean verbalizadas por los propios desarrolladores. Al mismo tiempo, debe guiar al grupo en la búsqueda de las soluciones para aquellos problemas que se puedan repetir en los siguientes ciclos.

Estas reuniones deben ser puntos de inflexión para aquellos problemas que se vengan repitiendo en varios sprints. No se trata de buscar culpables, sino soluciones, pero no hay que tener miedo a exponer los fallos de otros compañeros siempre que se haga de una forma respetuosa y constructiva. Sobre todo, es importante que la exposición de fallos y cosas a mejorar no sea la meta, sino la excusa para encontrar una solución.

Es muy recomendable exponer y hacer énfasis en aquellas cosas que se van mejorando en cada retrospectiva, sobre todo al final de la reunión, ya que sirve como bálsamo para aquellas situaciones que hayan podido minar la motivación del equipo, pero si los errores no deben ser tratados como catástrofes o errores individuales, la revisión de los puntos positivos deben evitar la autocomplacencia.

La retrospectiva es un proceso para buscar soluciones grupales, y por tanto la responsabilidad de solucionarlos debe ser grupal, por ello, es recomendable realizar un diario de retrospectivas en el que se recojan los errores, aciertos y soluciones propuestas. De esta forma es más fácil ver los patrones que se repiten en los ciclos. Además, la implementación de las soluciones debe procurar ser colectiva, salvo en los casos en los que la difusión de la responsabilidad se haya constatado en sucesivos ciclos o la propia naturaleza de la tarea lo impida.

El Product Owner

El Product Owner

por | Jul 17, 2018

Qué es un Product Owner

El Product Owner es el encargado de añadir valor al producto. Aunque su nombre se traduzca como “dueño del producto” en realidad no tiene por qué ser así. El Product Owner es la persona más implicada con el proyecto, o mejor dicho, con la correcta realización del proyecto. Lo óptimo es contar con el propio cliente pero muchas veces no puede ser así. A veces no tiene tiempo y otras veces no lo ve necesario. En el peor de los casos no se implica lo suficiente, con lo que el resultado es frustrante para todos: si el Product Owner no colabora (en realidad cualquier actor de Scrum), todo se paraliza.

Decíamos que el Product Owner no tiene que ser el que paga por el producto. En ocasiones es incluso una persona del equipo de desarrollo, y aunque no es lo deseable, para proyectos simples o muy manidos es una solución al peor de los males descritos. Lo verdaderamente importante del Product Owner es que tenga una visión clara del proyecto, no solo interna (cómo funciona, cómo son los ritmos, etc), sino externa (cuáles son las fortalezas y carencias del sector al que va dirigido el proyecto, las oportunidades que ofrece, etc). En definitiva, el Product Owner se encarga de añadir valor al proyecto.

Funciones y características de un dueño de producto

Idealmente el dueño del producto debería ser una persona abierta al cambio, comunicativa, activa en el desarrollo, comprometida con todos los actores de Scrum y estar disponible frecuentemente para aclarar las dudas del equipo de desarrollo. La función principal del Product Owner es la de añadir al Backlog del proyecto aquellos requerimientos que supongan un incremento del valor del producto. Únicamente el Product Owner puede añadir y eliminar tareas al Backlog, asignándoles distintas prioridades y especificando cuándo se considera completa.

El dueño del producto debe además poseer unas buenas dotes comunicativas. Si quieres que el equipo de desarrollo junto con el Scrum Master hagan lo que quieres, será mejor que sepas comunicarlo adecuadamente. Pero no solo se comunicará con el equipo de desarrollo, el Product Owner va a tener muchos canales abiertos, y en cada uno va a existir una persona interesada en que se satisfagan sus necesidades en la siguiente versión. Por eso, es importante comprender que el Product Owner no es alguien que paga por el desarrollo, sino la persona que tiene la visión global y de futuro de todo el producto. Obtiene información de muchas fuentes, pero en última instancia es él o ella quien decide qué se debe implementar y qué no, en definitiva, qué aporta valor al producto.

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

Hablábamos anteriormente de la necesidad de contar con un Product Owner con buenas dotes comunicativas. Esto se hace indispensable cuando interactúa con el equipo. El Product Owner es el encargado de decir qué quiere al equipo y dependerá de esa buena comunicación la realización más o menos fiel del proyecto que imagina. La comunicación se efectúa a través del Backlog. A mayor concreción de lo que se pretende conseguir en el Backlog, menos debería ser el uso de otros tipos de canales, que pueden ralentizar el flujo de desarrollo. Solamente el Product Owner es capaz de añadir, y eliminar requerimientos del Backlog, pero no puede obligar al equipo a efectuar un numero determinado de tareas en cada sprint. Serán otros factores los que determinen esto último.

El Product Owner debe velar porque todo el equipo comprender qué es lo que quiere y en ningún momento actuar como un “jefe” imponiendo sus ritmos o la forma en la que se implementan sus ideas. Debe ser el equipo el que encuentre las soluciones a los distintos problemas o requerimientos del cliente, pues el Product Owner debe entender que ellos son los profesionales y quienes tienen más experiencia en el campo. El Product Owner es el encargado de guiar todo el proceso hacia la idea que tiene en mente.

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

El punto de encuentro entre estos dos actores es el Backlog, pero ambos lo usan de forma distinta. Mientras que para el Product Owner es el tablero sobre el que pone las ideas para añadir valor al producto, el Scrum Master es el encargado de velar por la integridad del equipo. Esto no quiere decir que deba existir un conflicto. Este punto de encuentro puede ser muy enriquecedor para ambas partes. Por un lado, el Product Owner puede reinterpretar ciertas tareas para aprovechar al máximo las capacidades del equipo cuyo máximo conocimiento está en manos del Scrum Master y por otro, el Scrum Master puede tener una idea mucho más cercana de lo que se pretende para comunicársela al equipo. La sinergia entre estos dos roles deriva muchas veces en una motivación mayor en el equipo, pues se concretan mucho más los objetivos y se hacen más realistas.

El Scrum Master actúa además como un intermediario entre el equipo y el Product Owner. Aunque el Product Owner se comunica indirectamente con el equipo a través del Backlog, éste puede transmitirle sus preocupaciones o ideas al equipo a través del Scrum Master, que a su vez podrá hacer lo propio con el Product Owner.

El dueño de producto en el Scrum diario

Como todos los miembros del equipo el Product Owner está invitado a participar en el Scrum diario para conocer cómo se está desarrollando el proyecto. Es recomendable su asistencia porque pueden existir malinterpretaciones de las tareas existentes en el Backlog y es útil detectar estas a tiempo, pues de otra forma se habrá perdido un tiempo valioso.

Durante el Scrum diario, el Product Owner deberá dejar el protagonismo a los demás miembros del equipo limitándose a aclarar las dudas que existan. Bajo ningún concepto debe guiar el flujo de trabajo, añadir tareas que no estaban en el Backlog o pisar el terreno de otros roles. Por mucho que tenga conocimiento de la tarea que se esté realizando, no debe imponer su criterio sobre el equipo de desarrollo, ya que lo que busca la metodología Scrum es el aprendizaje mediante el fallo al final de cada ciclo y estas actitudes aunque pueden prevenir el error, hacen al equipo dependiente e impide que madure.

El dueño de producto durante la planificación del Sprint

La planificación del Sprint es un ritual de vital importancia para el Product Owner. Al ser la única persona con conocimiento profundo del producto y el único que es capaz de modificar el Backlog, se hace indispensable su presencia en la planificación del sprint. Para ello, debe priorizar las tareas que hay en el Backlog, así como asignar las dependencias entre ellas con el objetivo de no introducir el sprint tareas que no se pueden llevar a cabo sin la inclusión de otras.

Es necesario que se cercione de que las tareas son claras, entendibles y tienen un punto de finalización o un objetivo concreto y mesurable. Durante este proceso el Product Owner debe ser capaz de transmitir la importancia de las tareas que pretende llevar al sprint para hacer partícipe al equipo de la necesidad de su correcta realización y el impacto que tendrán en el producto que se está desarrollando. Una vez explicadas las tareas, hay que fijar los objetivos del sprint. Este objetivo pueden ser varios, una mejora de la experiencia del usuario, una funcionalidad y en resumen, cualquier añadido que el Product Owner considere que agrega valor al producto.

Una vez el Product Owner haya explicado cual pretende ser su meta para el sprint, la reunión girará en torno a la negociación para la creación del Backlog del sprint. En este momento, el Product Owner debe respetar las impresiones del resto del equipo, ya que los recursos, conocimientos y tiempos para el sprint no son infinitos y una sobrecarga del Backlog del sprint puede evitar que se llegue a buen término el ciclo de Scum. Por tanto, la ultima palabra sobre lo que se añade o no a la pila de tareas del sprint la tiene el equipo.

Debe mantener en todo momento un ambiente estimulante e intentar que el equipo se esfuerce al máximo pero sin llevarlo más allá del límite. Para ello, el Scrum Master intentará llegar a un consenso entre ambos actores, pues es quien tiene el conocimiento y la impresión global más experta de las virtudes y carencias del equipo.

El dueño de producto durante la revisión del Sprint

Durante la revisión del sprint todos los actores se reúnen para ver y probar todos los avances que se han realizado durante el sprint. El Product Owner tiene que guiar la reunión, revisando una por una todas las tareas introducidas en el sprint y pidiendo al equipo que le demuestre que se han completado. Aquí es donde cobra especial relevancia la clarificación del objetivo de cada tarea y que sea cuantificable. En el caso de que una tarea haya cumplido con todos los requisitos de finalización se considerará terminada y en el caso de que no haya podido ser así, tendrá que actualizarse si así lo considera el Product Owner para futuros sprints.

Una vez exploradas las nuevas funcionalidades del producto el Product Owner explicará como afectan esos cambios al sprint y cual es la visión a futuro para hacer a todos los integrantes partícipes.

El dueño de producto durante la retrospectiva

Aunque a primera vista no parece que tenga mucho sentido que el dueño del producto aparezca en esta reunión, su presencia no es menospreciable. A pesar de que su intervención en un sprint debe ser mínima, esta reunión puede servirle para enriquecer su conocimiento del equipo, ver sus dificultades e incluso hacer autocrítica. Puede que descubra que algunas tareas que no fueron implementadas correctamente en el sprint y fueron marcadas como incompletas en su revisión, no hayan salido adelante por una falta de clarificación de las mismas en el Backlog, o por diversas dificultades del equipo. Puede que se de cuenta de que algunas funcionalidades que tiene pensadas sean excesivamente complejas para verlas en una versión a corto plazo y eso puede ayudar a planificar mejor las nuevas funcionalidades en función de su prioridad y hacerse una idea más precisa de los tiempos del proyecto.