La lección del fuego

Hace ya algún tiempo leí el libro "Coaching: El arte de soplar brasas en acción" de Leonardo Walk y una de las cosas que me llamó la atención un texto en relación al Coaching Grupal que titula "La lección del fuego", y que resumo a continuación.

El texto hace referencia a un hombre que abandona el grupo en el que participaba sin ningún motivo aparente. Tras un tiempo, el líder del grupo le visita y sin mencionar palabra alguna le hace meditar acerca de su separación del grupo y cómo afecta esa circunstancia tanto a él mismo como al resto. Para conseguir la reflexión aprovecha los leños que ardían en la chimenea. El líder aparta uno de los leños del grupo, y al poco tiempo se extingue su llama, a la vez que el resto del grupo pasa a arder con menos intensidad. La separación de uno de los miembros del grupo le ha afectado a él, pero también al grupo en conjunto.

Pasados unos momentos, el líder vuelve a incluir dicho leño al grupo, y a la vez que el leño vuelve a encenderse, el grupo también ve incrementada su fuerza gracias a la contribución del leño individual.

La moraleja es que todos los miembros de un grupo deben integrarse y contribuir en el equipo y gracias a la cohesión de todos y cada uno de ellos se consigue maximizar el rendimiento tanto individual como colectivo.

Tengámoslo en cuenta cada vez que nos planteemos "remar en nuestra propia dirección" o incluso "dejar de remar" sin tener en cuenta los intereses del grupo.

La teoría de las venganzas

Con este post inicio una breve serie en la que quiero abordar el conflicto.

Primero de todo hay que definir el conflicto. Es cualquier situación no armónica que se genera entre dos o más personas o grupos de personas. Supone un desacuerdo expreso o tácito que genera tensión y malestar, porque afecta negativamente a la relación entre las partes implicadas o a los resultados que habrían de obtenerse de la interacción entre ellos.

En este post distinguiré entre conflicto y problema. Me referiré al conflicto cuando se produce entre personas, mientras que los problemas se refieren a cualquier situación o elemento (pueden ser cosas, procedimientos, procesos, máquinas, etc) que nos apartan del desarrollo normal de nuestra actividad y propósitos. Es decir, el conflicto es un problema entre personas.

Una de las primeras características de un conflicto tiene que ver con la forma de materializarse, y puede ir desde la no exteriorización del conflicto (hablaré de conflicto latente) hasta la manifestación ostensible del mismo.

La gestión de conflictos no debe tener en cuenta únicamente la solución a aplicar, sino que se deben plantear las preguntas adecuadas para gestionar la dinámica del problema en general.

¿Cúando se puede producir un conflicto? Cuando determinados integrantes del equipo no ven satisfechas sus necesidades, no aprecian que se tengan en cuenta sus intereses, opiniones o ideas, o no sean apreciados sus comportamientos.

¿Qué efectos nos podemos encontrar si no se resuelven esos conflictos? Podemos encontrarnos situaciones de

• Hostilidad
• Resentimiento
• Pérdida de autoestima
• Pérdida de motivación
• Pérdida de cohesión del grupo

Y esto se puede traducir en una desvinculación de los objetivos del grupo, así como una disminución de la eficacia del equipo, con las consecuencias que puede generar, como menciono en el post sobre la parábola de los leños, el fuego y el trabajo en equipo.

Gestionar un conflicto no implica solamente tratar la situación que ha desembocado en el mismo, puesto que siempre pueden quedar "resentimientos" inevitables por nuestra condición humana.

Una buena gestión implica tratarlo antes de que se produzca. Pero, ¿es posible anticiparlo?

En las dinámicas de grupo en las que gestiono, algunas en forma de sesiones dirigidas de brainstorming, me gusta informar que cuando una persona (que denominaré A) hace un comentario sobre, por ejemplo, alguna de las ideas que se han generado por alguien que denominaré B, si dicho comentario es interpretado por B de forma negativa (aunque no fuese la intención inicial de A), en menos de 20 minutos (o sea, en el transcurso de la misma reunión) B lanzará algún comentario en modo de "venganza" hacia A. Es parte de la naturaleza humana, pero es una potencial fuente de conflicto, y por tanto, si no se rompe esa escalada de "violencia" se puede llegar a generar un conflicto.

En las reuniones en las que tengo un papel activo (incluidas las que actúo como facilitadora y/o coach), aprovecho cualquier ocasión para poner de manifiesto cualquier interpretación negativa que se haya hecho y menciono el comentario sobre las "venganzas" puesto que es la mejor forma de quitar hierro a esas interpretaciones personales de los comentarios que hacen los demás y sobretodo es una forma de eliminar las corrientes subterráneas que pueden generar conflicto.

El éxito en esa labor también depende en gran medida de la interpretación que hagan A y B de tu propia forma de gestionar el conflicto.

Sin embargo, y para finalizar, hay que tener en cuenta que frente a la idea tradicional de que todo conflicto es malo y hay que evitarlo, surgen otras formas de percibirlo y abordarlo mucho más prácticas ya que se puede interpretar como un resultado natural e inevitable en cualquier equipo o en las relaciones interpersonales, que además puede fomentar la creatividad y la espontaneidad y la evolución del propio equipo, tal como se puede leer en el post sobre las cuatro etapas de desarrollo de los equipos.

Análisis de las interacciones en un equipo para mejorar su eficacia

 En un post anterior hablaba de las cuatro fases de desarrollo de un equipo. En este voy a hablar de las interacciones que se producen en su seno, porque nos pueden ayudar considerablemente la "salud" del equipo.

En cuanto a las interacciones dentro de un equipo, se pueden dar básicamente de dos tipos

• Interacciones orientadas a acometer la tarea que tiene asignada el equipo. Se centran en el contenido, en lo que se hace en el grupo
• Interacciones orientadas a la actividad social del grupo. Se enfocan en el proceso, en cómo el equipo lleva a cabo las tareas que tiene asignadas, en el funcionamiento del mismo, etc.

En este segundo tipo de interacciones, nos podemos encontrar con interacciones positivas (contribuyen al desarrollo y avance del grupo) o negativas (dificultan o entorpecen el desarrollo y avance del grupo).

Cuando se producen interacciones negativas, como por ejemplo, hostilidad, silencios, "venganzas", etc, hay que considerarlas como un síntoma de que está pasando algo y hay que actuar para solucionarlo (podemos estar entrando en la fase de Conflicto a pesar de haberla superado en el pasado). Por ejemplo es posible que no se esté teniendo en cuenta la satisfacción de ciertas necesidades individuales de alguno o varios de los miembros del equipo, y se esté haciendo excesivo énfasis en la tarea.

La observación de estas interacciones nos puede ayudar considerablemente a determinar si el funcionamiento del equipo es o no eficaz. Y es importante destacar que no sólo el líder debe ser capaz de esta observación, sino que cada miembro debe desarrollar la capacidad de observación de las interacciones en el grupo, de modo que se conviertan a la vez en participantes y observadores.

Tras esta observación y una puesta en común se podrá llevar a cabo un análisis de qué está pasando en el equipo, determinar qué es lo que enfatizar (cuando se hayan observado puntos positivos y fuertes en las interacciones, ya que no me quiero centrar solo en la parte negativa de las interacciones que sería lo más fácil siguiendo nuestra cultura latina), qué se quiere mejorar (cuando se detecten puntos negativos o débiles) y cuáles son los siguientes pasos a dar.

Entre los patrones de comunicación y participación que se da entre los miembros se puede analizar

• Cómo participan los miembros del equipo y en qué grado
• ¿Se comparte el conocimiento? y ¿cómo se lleva a cabo esa compartición?
• ¿Existen necesidades de comunicación que no están satisfechas en el grupo?
• Cuando hay que tomar decisiones ¿cómo se toman?, ¿hay aportaciones, sugerencias, comentarios de los miembros del equipo antes de tomar una decisión?
• Cuando hay un conflicto latente ¿cómo actúan los distintos miembros del equipo? ¿cómo se ponen de manifiesto dichos conflictos?, ¿quién interviene?, ¿con qué ánimo lo hace?, ¿hay venganzas en el equipo?
• ¿Se cuestionan las directrices del líder?
• Los miembros del equipo ¿manifiestan su apoyo al líder y al resto de miembros? ¿lo hacen en privado o públicamente?
• ¿Se reconocen los éxitos tanto del equipo como individuales? ¿quién hace esos reconocimientos?
• ¿Se agradece la colaboración o ayuda prestada por los miembros del equipo?
• ¿Se manifiestan las inquietudes, temores, miedos en el equipo?
• ¿Hay feedback de las aportaciones o de las decisiones tomadas? ¿es constructivo o destructivo?
• Etc.

Si somos capaces de observar y analizar estas interacciones, podremos determinar no sólo los puntos fuertes y que por tanto merezca la pena seguir cultivando, sino también los puntos débiles que sobre los que haya que trabajar para mejorar la eficacia de nuestro equipo.

Cuándo tomar las decisiones

La toma de decisiones es un proceso importante en la vida diaria de cualquier persona y por tanto también en la actividad cotidiana de los equipos Agile.

Pero, ¿es necesario contar con toda la información necesaria y tenerla analizada antes de tomar una decisión? Si la respuesta fuese afirmativa podríamos llegar a encontrarnos en una situación de "parálisis por análisis". Es decir, si hipotéticamente esa fuese nuestra forma de proceder no podríamos tomar una decisión si no hemos recopilado y analizado toda la información. Pero en un momento como en el que nos encontramos, que se denomina la era de la información, podríamos estar indefinidamente recopilando información y analizándola antes de tomar decisiones, por lo que nos quedaríamos "paralizados" sin tomar una decisión.

Entonces, ¿cuándo es el mejor momento para tomar una decisión?

No es posible determinar el momento oportuno, pero lo cierto es que la mejor decisión es aquella que se toma en el momento más cercano a su aplicación. Esto no significa que haya que retrasar la toma de decisiones indefinidamente, sino que, dado que las situaciones a las que nos enfrentamos todos los días son cambiantes, las variables a considerar también lo serán y por tanto cuanto más cercanos estén en el tiempo la toma de decisión y la aplicación de la misma, mejor será esta. Si procedemos de esta forma contaremos con información más "fresca" y consecuentemente llegaremos a una mejor decisión. Por ejemplo, en una decisión que hubiésemos tomado hace dos meses y que debamos aplicar hoy, existe la posibilidad de que las variables que nos ayudaron a dar el paso hayan cambiado, por lo que la decisión puede no ser ya válida.

Si aplicamos esta idea a Agile, lo podemos traducir en, diferentes formas, que voy a intentar ilustrar con algunos ejemplos:

• Los requisitos de un determinado producto o de una feature es mejor que no estén definidos todos desde el principio, sino que tienen que irse definiendo en el momento oportuno, cuando se conozca la infomación necesaria para poder hacer una definición más adecuada a la evolución del producto y las necesidades de los clintes
• Las Historias de Usuario, no se tienen que estimar de forma precisa todas al principio del desarrollo, sino que solo es necesario tener una estimación fidedigna de aquellas que se van a abordar en la siguiente iteración o las dos siguientes. Estimar el resto de Historias de Usuario en una fase temprana puede requerir volverlas a estimar cuando se vaya a trabajar realmente en ellas, con la información actual de las necesidades del usuario, la evolución que ha tenido el producto en ese tiempo y los incrementos ya existentes, etc.

Por eso, las decisiones se deben tomar en el momento más cercado a su aplicación.

Los Tres Roles Agile

El Equipo Agile es uno de los tres roles indispensables en Agile.

En las diferentes metodologías Agile se definen principalmente tres roles con actividades y responsabilidades muy diferenciadas:

• El Product Owner
• El Scrum Master
• El Equipo (el Team)

El Product Owner es el encargado de tener un diálogo constante con los stakeholderls y los clientes.

• En ese diálogo conoce y comprende las necesidades de los clientes y del negocio.,
• Con esa información, utlizando unos criterios concretos, define las historias de usuario que debe abordar el equipo y establece las prioridades de las mismas, es decir, determina qué se debe llevar a cabo y en qué orden para poder ofrecer valor al cliente y satisfacer la estrategia del negocio.
• ...

El Scrum Master es el facilitador del equipo. Se encarga de:

• Dirigir las diferentes ceremonias que tienen lugar antes, durante y después de la iteración.
• Eliminar los impedimentos que el equipo encuentra durante el desarrollo de su trabajo.
• Proteger al equipo de interferencias externas. Es el paraguas que pone freno a peticiones que llegan durante la iteración, tiene la potestad de abortar una iteración si el trabajo de equipo ha perdido sentido (por ejemplo, porque el feedback recibido de los stakeholders ha cambiado radicalmente el rumbo y/o las prioridades de la actividad), etc.
• ...

El Equipo Agile está compuesto por el Product Owner, el Scrum Master y el equipo de desarrollo. En las primeras definiciones de Agile, el equipo no incluía el Product Owner ni el Scrum Master como miembros del equipo, pero finalmente sí se han incluído. El equipo de desarrollo tiene que:

• Encargarse de desarrollar el trabajo que el Product Owner ha definido como prioritario en sus negociaciones con los clientes y stakeholders.
• Comprometerse y entregar una parte de ese trabajo, terminado, probado y validado y funcionando
• Disponer de un perfil cross-funcional para poder abordar internamente todas las fases del producto, desde la definición y la implementación, hasta la validación, verificación e incluso en algunos casos el deployment.
• ...

Para más detalles, pincha cada uno de los enlaces (Product Owner, Scrum Master y Equipo Agile).

El Equipo Agile

El Equipo Agile es uno de los tres roles indispensables en Agile.

El Equipo Agile es un grupo auto-organizado de personas más o menos pequeño con un objetivo común, con unos perfiles complementarios y un conocimiento entre miembros que debe ir evolucionando hacia un team de alto rendimiento. Además tienen que ser un equipo auto-organizado, auto-gestionado y compuesto por integrantes motivados y empoderados. Obviamente esto no se consigue desde el mismo día que se crea el equipo ni sin esfuerzo alguno (véase, por ejemplo, las cuatro etapas del desarrollo de los equipos).

Aquí hay que diferenciar entre el equipo Agile y el equipo de desarrollo. El equipo Agile incluye el equipo de desarrollo (los que implementan las historias de usuario seleccionadas) y dos roles específicos adicionales, que son miembros del equipo al mismo tiempo que tienen una función diferente, el Product Owner y el Scrum Master.

En relación con la mencionada complementariedad de los perfiles, en Agile los teams son cross-funcionales, lo que significa que pueden llevar a cabo todas las tareas necesarias para entregar valor al cliente (definir, crear/construir/desarrollar, probar, verificar, entregar). Esta cross-funcionalidad intra-team limita el número de handovers necesarios y los retrasos que puedan conllevar para concluir el trabajo asignado. Es muy habitual que la cross-funcionalidad la entiendan algunas personas como que cada uno de los miembros del equipo tiene que saber hacer de todo, mientras que en realidad la cross-funcionalidad se fundamenta en que sea el team quien pueda y sepa hacerlo todo. 

Respecto al tamaño del equipo de desarrollo hay diversidad de opiniones, desde que debe tener 6 miembros (más/menos tres, es decir, desde 3 hasta 9 miembros) hasta que debe tener entre 5 y 11 integrantes. Obviamente, no hay una cifra mágica ni ópima, pero el equipo no debe ser demasiado pequeño (para poder cubrir todos los perfiles necesarios) ni demasiado grande (para minimizar las tareas de coordinación, alineamineto entre miembros, etc.). Tampoco es necesario que todos los equipos de una organización tengan el mismo tamaño, dependerá de las asignaciones que reciban los equipos, los perfiles de los integrantes, etc.

El equipo Agile en un trabajo conjunto con el Product Owner (miembro del equipo) define qué van a abordar en la siguiente iteración y con qué orden o prioridad. Además el equipo, al inicio de la iteración se compromete a entregar una parte (la más prioritaria) del trabajo que hay pendiente, terminado, probado, validado y funcionando y para ello cuentan con la ayuda del Scrum Master que facilitará el flujo de trabajo y se encargará de eliminar los impedimentos que se vayan encontrando durante la iteración.

Si el Product Owner es quien le dice al equipo qué deben hacer, es el propio equipo de desarrollo quien define cómo implementarlo.

Nuevamente es necesario hacer referencia a Inspeccionar y Adaptar, para conseguir que un equipo cualquiera se convierta en un equipo de alto rendimiento, de modo que en esa inspección deben tocar temas tan ámplios como la organización, el trabajo, los impedimentos encontrados, cómo se han enfrentado cada uno de ellos y como equipo a las diferentes situaciones, las dinámicas entre ellos mismos y entre el equipo y el exterior, etc.

Los grandes equipos requieren algo más que miembros con mucho talento. La composición del equipo y la dinámica existente tienen un elevado impacto en los resultados del mismo. Los equipos de alto rendimiento tienen unas características en común:

• Un entorno seguro para asumir riesgos sin temor a penalizaciones o situaciones embarazosas
• Alineamiento en una visión compartida con unos objetivos y propósito claros y comunes
• Diversidad en los conocimientos y en sus competencias (incluidas las soft-skills) para poder tomar decisiones de forma independiente
• Confianza mutua
• Responsabilidad hacia cada uno de los miembros del equipo y hacia la organización en general
• Capacidad de completar el trabajo encomendado con calidad, cumpliendo los compromisos adquiridos

El Product Owner

El Product Owner es uno de los tres roles que se pueden encontrar en Agile.

El Product Owner es el responsable de definir las Historias de Usuario (User Stories) y priorizar el backlog del team. Su papel principal es maximizar el valor producido por el equipo y asegurar que las historias que se crean satisfacen las necesidades del usuario y cumplen la Definición de Hecho (Definition of Done, DoD).

El Product Owner es el punto de contacto entre el cliente y el equipo y debe tener una relación muy estrecha con Product Management y otros stakeholders (incluyendo otros Product Owners), con el objetivo de poder definir y priorizar las historias de usuario en el backlog del equipo.

Veamos algunas de las responsabilidades del Product Owner:

• Actualizar y mantener el backlog antes de la planificación de las iteraciones. El Product Owner tiene un diálogo constante con los clientes y stakeholders para conocer sus necesidades y las del negocio, y antes de la reunión de planificación de la iteracion, el Product Owner debe actualizar el backlog del equipo incluyendo nuevas historias que hayan aparecido, eliminando otras que ya no tengan sentido (o reduciendo considerablemente su prioridad), y debe actualizar la prioridad de todas ellas según unos criterios concretos. El backlog también incluye mejoras, refactoring, etc. y el Product Owner es el responsable de priorizar todos los elementos, basándose en el valor para el usuario, el tiempo, y posibles dependencias con otros teams o productos.
• Participar en la planificación de las iteraciones.  Durante el evento de planificación, es el responsable de que las historias de usuario que se van a abordar en la iteración estén claras para el equipo y ayuda a definir el objetivo de la iteración que se está planificando. También es responsable de coordinar las dependencias con otros Product Owners. Durante la planificaciión se encarga de que el equipo esté alineado y lleguen a un acuerdo sobre el objetivo y resultado finales de la iteración.
• Aceptar las historias. El product Owner trabaja con el equipo para aceptar las historias completadas. Esto incluye validar que dichas historias cumplen los criterios de aceptación (Acceptance Criteria), que incluye los test necesarios para ser aceptada y que cumple con la Definicion de Hecho (Definition of Done) de cada historia. De este modo el Product Owner asegura el nivel de calidad de las entregas del equipo.
• Participar en la Revisión. El Product Owner colabora con el team y con cualquier otro stakeholder involucrado e interesado en la revisión de los resultados que el equipo entrega en esa iteración.
• Participar en la Retrospectiva. El Product Owner es un miembro más del equipo a la hora de Inpeccionar y Adaptar, y la retrospectiva es un claro exponente de esta parte del proceso de evolución del team. Durante esta retrospectiva pueden aparecer ideas de mejora del producto y el Product Owner debe estar involucrado en las discusiones para conocer el alcance y el impacto de esas mejoras y de ese modo tener la capacidad de incluirlas en el backlog y priorizarlas.

Si bien en las primeras propuestas de Agile (y Scrum) el Product Owner estaba excluido de las retrospectivas, en recientes versiones del marco de trabajo y de la metodología se le incluye dada su perspectiva y su contribución a mejorar el rendimiento del proceso, el equipo y el producto. En soluciones intermedias lo que se acuerda con el equipo y el propio Product Owner es que este último participa en la ceremonia y cuando falta un rato para concluir se ausenta, para que el equipo tenga total libertad de hacer mención específica de aspectos relacionados directamente con este rol y/o con la persona, manteniendo la confidencialidad de quién o quiénes han emitido los comentarios y opiniones.

El rol del Product Owner es crítico, y normalmente requiere una persona con dedicación completa a un team, o como máximo dos teams.

El Scrum Master

El Scrum Master es uno de los tres roles que se pueden encontrar en Agile.

El Scrum Master es coach y líder al servicio del equipo Agile. Es el encargado de velar por que el equipo conozca y aplique el marco de trabajo (framework) o la metodología seleccionados, asegurando que están de acuerdo y siguen el proceso Agile. El Scrum Master también es el encargado de eliminar (o contribuir a que se eliminen) los impedimentos con los que se va encontrando el equipo durante la ejecución de las iteraciones. Y contribuye a establecer un entorno para que se produzcan las dinámicas necesarias que favorezcan un alto rendimiento del equipo en constante mejora.

El Scrum Master consume la mayor parte de su tiempo ayudando a los miembros del equipo a comunicarse, coordinarse, cooperar y a conseguir los objetivos que se ha fijado el team para la iteración en curso.

Veamos a continuación algunas de las responsabilidades básicas del Scrum Master:

• Muestra liderazgo. Debe liderar con el ejemplo y para ello debe tener una mentalidad Agile (o mejor, Lean-Agile) muy arraigada, y gracias a ello será capaz de ayudar al equipo a adoptar y aplicar los valores, principios y prácticas del marco Lean-Agile seleccionado por ellos o por la organización a la que pertenecen.
• Refuerza el marco de trabajo establecido en el equipo. Ese marco de trabajo puede ser tan ligero como se acuerde, pero una vez establecido es el encargado de velar por que se siga y que, por ejemplo, se celebren las ceremonias Agile acordadas, se mantenga el máximo máximo de trabajo paralelo (Work in Progress o WIP), etc.
• Facilita el progreso del team hacia los objetivos del mismo. El Scrum Master es un facilitador que contribuye al establecimiento y mejora del flujo de trabajo, la velocidad, la predictabilidad y la calidad. Para ello, en ocasiones deberá cuestionar la vigencia de las normas establecidas y ayudar al equipo a pensar si hay posibles mejoras que deban plantearse.
• Dirige los esfuerzos del equipo hacia una mejora constante. Ayuda al equipo a mejorar y toma la responsabilidades de sus acciones, y facilina las retrospectivas del equipo, utilizando y enseñándoles técnicas de resolución de problemas, si fuese necesario.
• Facilita los eventos. Debe asegurarse que las ceremonias (e.g. reuniones diarias, planificación, revisión, retrospectiva) tienen lugar, que son productivas y que mantienen el límite de tiempo acordado.
• Facilita la eliminación de impedimentos, gestionando y eliminando aquellos que están fuera del alcance del equipo y que involucran a otros team o a la organización en general. Al mismo tiempo que elimina los impedimentos, está ayudando al equipo a conseguir los objetivos que habían definido para la iteración.
• Ayuda al Product Owner a gestionar el backlog del equipo (y del producto, si fuera necesario) y a establecer un equilibrio entre las prioridades y el alcance de la iteración.
• Protege al equipo de interferencias externas. Es el paraguas que pone freno a peticiones que llegan durante la iteracion, tiene la potestad de abortar una iteración si el trabajo del equipo ha perdido sentido (por ejemplo, porque los requisitos o las prioridades han cambiado radicalmente), etc.
• Construye un equipo de alto rendimiento, ayudando a los miembros del mismo a transitar en las diferentes etapas de evolución de los equipos, ayuda a resolver internamente los conflictos interpersonales e identifica las posibles oportunidades de crecimiento. Solo escala los problemas personales a otros niveles cuando el proceso interno no ha conseguido solventarlos.

Aunque lo ideal es que un Scrum Master tenga dedicación completa a un equipo, esto no siempre tiene sentido (por volumen de trabajo o por cuestiones económicas). Habitualmente un Scrum Master da servicio a varios equipos de trabajo (idealmente no deberían ser más de tres), lo que ayuda también a la coordinación y comunicación entre equipos.

Algunas empresas incluso llegan a "sacrificar" el rol del Scrum Master como tal y en su lugar pueden tener un Agile Coach para toda la organización (por ejemplo un Agile Coach para 15 equipos en 4 ubicaciones físicas diferentes) que se encarga de velar por las ceremonias que no son diarias y el marco de trabajo y el resto de las actividades de "delegan" en los miembros del equipo, en el Product Owner o en los managers del equipo. Si bien esta situación no es la ideal, cada empresa debe tener en consideración sus circunstancias y condicionantes y a partir de ahí definir su estructura. Una vez se haya tomado la decisión, se debe conseguir que todos los integrantes de la organizaicon tengan claro el marco (setup) establecido y lo apoyen. Y, por qué no, al cabo de unos meses se puede hacer un ejercicio de Inspeccionar y Adaptar y valorar si la decisión tomada en aquel momento, con la informaicón con la que se contaba, sigue siendo válida y mantenerla o modificarla en función de las nuevas condiciones e información.

Las Ceremonias Agile

Dentro de algunos marcos Agile (como por ejemplo Scrum) se definen varias ceremonias que tienen lugar durante la iteración.

• Reunión diaria. Se conoce como el Daily Stand-up. Es una reunón diaria que dura alrededor de 15 minutos. Tiene lugar de pie (por eso se llama stand-up), para fomentar que se vaya al grano y termine en un plazo breve. Durante esa reunión cada uno de los miembros del equipo tiene que responder a tres preguntas:
• Qué hice a lo largo del día de ayer
• Qué voy a hacer hoy
• Qué impedimentos me estoy encontrando para poder avanzar

Es importante que al resumir la actividad incluida en esos tres puntos, los comentarios de los miembros del equipo estén enfocados en qué valor están aportando y que impedimentos se encuentran para alcanzar el objetivo de la iteración con el que se habían comprometido, y por tanto conseguir entregar el valor esperado.

Si durante la reunión aparece algún tema que se quiere o debe discutir con el team (por ejemplo tratar algún impedimento mencionado), se "aparca" hasta que todos los integrantes del equipo hayan intervenido respondiendo a las tres preguntas. Una vez todos han mencionado los avances diarios, los planes para ese día y los impedimentos que tienen (si los hay), se continúa la conversación trantado los temas que se han "aparcado", y en ese caso, los miembros del team que no estén involucrados en ese tema pueden quedarse o abandonar la reunión y volver a sus tareas, y ya serán informados del resultado final de la discusión.

• Plantificación, o Iteration Planning. Esta reunión tiene lugar al inicio de la iteración. En ella, se establece una conversación entre los miembros del equipo y el Product Owner para,
• Comentar y aclarar dudas sobre las Historias de Usuario (User Stories) más prioritarias, 
• Hacer estimaciones de cuánto esfuerzo les puede requerir llevar a cabo cada una de las Historias de Usuario (en otro post hablaremos de cómo se pueden hace esas estimaciones)
• Identificar qué necesidades específicas tiene el equipo para poder llevar a cabo su trabajo en esa iteración
• Analizar qué impedimentos se pueden encontrar
• Evaluar con qué recursos cuenta el team durante esa iteración
• Comprometerse a abordar un conjunto de las Historias de Usuario (las más prioritarias), con los recursos con los que cuentan y con las estimaciones del esfuerzo requerido
• Obtener el OK del Product Owner respecto al compromiso que está adquiriendo el equipo
• Revisión, o Iteration Review. Esta reunión tiene lugar al finalizar la iteración. En ella el equipo presenta los resultados del trabajo que han llevado a cabo durante la iteración. Una buena práctica es presentar los compromisos adquiridos durante la Planificación y a continuación los logros obtenidos, de modo que sea sencillo comprender qué se esperaba y qué se ha conseguido.
• Retrospectiva, o Iteration Retrospective. En esta ceremonia se analiza cómo ha ido la iteración que acaban de concluir, incluyendo tanto los aspectos positivos que se han encontrado, como abordando los aspectos y áreas de mejora que han detectado. El ámbito de la retrospectiva, puede incluir consideraciones tanto de las historias abordadas, como el propio el equipo y sus interacciones, la relaciones entre el equipo y otros equipos u otros entes externos al equipo, etc. Es importante que, cuando sea posible, el equipo defina puntos de acción que quiere trabajar para mejorar su rendimiento y eficiencia, para así porde evolucionar.

Cuando el proyecto abordado es de gran envergadura, y se tiene varios equipos que trabajan simultáneamente y de forma interrelacionada, se habla de "escalar Agile" y en ese caso, y en función del marco de escalado se que considere (veremos algunos en otros posts), pueden aparecer más ceremonias (o incluso alguna de ellas, como la retrospectiva se puede desdoblar en dos, para abordar el conjunto de equipos y cada uno de estos de forma individual). De esto hablaremos en otros posts.

Inspeccionar y Adaptar

Agile hace un especial énfasis en la importancia de la mejora continua. No en vano incluye un principio que dice “En intervalos regulares, el equipo reflexiona sobre cómo ser más eficiente, y ajusta su comportamiento en función de ello” (Aquí puedes ver los doce principios).

Inspeccionar y Adaptar se puede aplicar a cualquier ámbito de la vida (tanto personal como profesional), tanto en la ejecución de la última iteración Agile, como en un modo de trabajo (Way of Working, WoW) que se ha definido, como en cualquier decisión que se toma y que se pueda revisar y modificar si se considera oportuno.

Pero volvamos a Agile y los equipos de trabajo. Una de las ceremonias Agile es la retrospectiva, que se debe realizar una vez que concluye una iteración, y antes de comenzar la siguiente. Esta ceremonia es de suma importancia, puesto que es la reflexión de la iteración que acaba de concluir

Al mismo tiempo, un agile coach debe enfatizar que, en realidad, los equipos agile cuentan con cuatro ceremonias en las que se puede producir esa inspección y adaptación de forma más o menos natural, sin necesidad de hacer un análisis detallado de qué ha ido bien y qué se puede mejorar:

• Las reuniones diarias (daily o dailies)
• La planificación de la iteración (iteration planning)
• La revisión de la iteración (iteration review)
• La retrospectiva (retrospective)

En todas ellas, el team tiene la oportunidad de reflexionar y adaptar el curso de su trabajo y su actuación. Veamos algunos ejemplos:

• En las reuniones diarias. Cuando los miembros del equipo notifican en qué han avanzado, qué tiene previsto abordar, y qué impedimentos se pueden encontrar, pueden reflexionar sobre algunas tareas que no habían identificado inicialmente, sobre un impedimento o un riesgo que no habían considerado, una tarea que ya no tiene sentido llevar a cabo, etc.
• En la planificación de la iteración. Cuando el equipo va a definir con qué historias de usuario va a comprometerse durante la iteración que están a punto de comenzar, también pueden reflexionar sobre cuáles de ellas deben aparecer o desaparecer. Esta aparición o desaparición de historias puede ser  fruto de los avances de las iteraciones previas, que hayan permitido al quipo confirmar o desmentir hipótesis, desvelar nuevas consideraciones a tener en cuenta, etc, y que debido a ese avance, algunas nuevas historias aparezcan y otras pierdan su relevancia o incluso ya no tengan sentido.
• En la revisión de la iteración. Cuando el equipo muestra el avance conseguido durante la iteración que acaba de concluir y comenta el valor aportado en la misma, los stakeholders presentes en dicha reunión proporcionarán su feedback, que es de gran utilidad para el equipo puesto que aporta información relacionado con cómo las necesidades de los clientes se ven satisfechas con dicho valor aportado y puede ayudar a confirmar el rumbo de los desarrollos o ayudar a definir cualquier cambio de orientación que sea necesario.
• En las retrospectivas. Esta reunión es la que siempre se ha considerado el punto básico en el que hacer esa inspección y adaptación. La forma de abordar esta reunión puede ser muy variopinta (y lo trataremos en otro post), pero es importante reflexionar sobre el trabajo, el equipo, la forma de trabajar, la interacciones dentro del equipo y hacia fuera (otros equipos, la organización en general, etc.), los impedimentos encontrados durante la iteración, la forma de reaccionar frente a dichos impedimentos, etc. Es muy importante, desde mi punto de vista que se aborde esta retrospectiva tanto de los aspectos positivos encontrados durante la iteración, como de aquellas áreas de mejora que pueden permitir al equipo evolucionar. Del mismo modo, se trata de identificar puntos fuertes que se deban mantener y puntos de mejora. Si ambos están centrados en el equipo mejor, ya que de este modo se identifican fortalezas del equipo y posibles puntos de acción que permita evolucionar hacia la excelencia.