Algunas diferencias entre Agile y Waterfall

En este post vamos a comentar algunas diferencias entre Agile y Waterfall en tres aspectos relevantes en la gestión de proyectos, los requisitos, la documentación y los entregables.

• Los Requisitos. Los Requisitos de un proyecto como las condiciones que debe satisfacer o las tareas que se deben completar para dar por concluido un proyecto. También se pueden entender como el conjunto de criterios dentro el alcance, o la lista de especificaciones que se deben cumplir en el proyecto.
• En Waterfall, probablemente necesitarás un documento que enumerará el alcance y los requisitos del producto. Necesitarás un plan de proyecto y para ello deberás disponer de un equipo de gente que se encargará de escribir y aprobar formalmente esos planes. Además, deberás establecer un board para el control de cambios con un proceso riguroso para gestionar cualquier cambio que se solicite o se requiera. Todo esto está pensado para proteger al equipo de crear algo que el cliente o los stakeholders no quieran y para minimizar cualquier cambio que pueda poner en riesgo el proyecto. Los planes de proyecto aprobados formalmente funcionan bien cuando la definición de los productos finales deseados está bien acotada y es conocida de antemano. Por ejemplo, un proyecto que tiene unos requisitos y objetivos claros basados en regulación existente. Pero si ese no es el caso, un equipo Waterfall corre el riesgo de crear un entregable completo, para inmediatamente descubrir que el cliente no necesita lo que se ha desarrollado.
• En Agile, los requisitos se tratan de una forma dinámica y pueden cambiar a medida que el equipo recibe feedback y dispone de nueva información. Inicialmente, en el lanzamiento del proyecto, hay definido un conjunto de requisitos, y ese conjunto o lista (o backlog) de requisitos crece y cambia constantemente a lo largo del proyecto. El equipo tiene que trabajar con los stakeholders para establecer las prioridades de esos requisitos, de modo que empiecen trabajando por los más prioritarios, que pueden ser los que aportan más valor o los más urgentes. El equipo seguirá trabajando en esos requisitos bajando de forma iterativa en la lista de prioridad, a medida que los primeros se van entregando. Al final de cada iteración, el equipo recibe feedback rápida y frecuentemente, y puede llevar a cabo los ajustes necesarios en los requisitos que todavía están en la lista antes de continuar con la siguiente iteración.

• La Documentación. Todos los proyectos necesitan documentación: planes de proyecto, mapas de stakeholders, planificaciones, contratos, etc.
• Los proyectos Waterfall requieren muchísima documentación, porque hay muchos traspasos (handovers) entre fases y entre los diferentes equipos de trabajo del proyecto. Además, como el trabajo se entrega en lotes muy grandes, es necesario crear mucha documentación en cada etapa del proyecto.
• En Agile también se requiere documentación. Sin embargo, en Agile se da prioridad a las conversaciones entre personas en tiempo real, lo que implica que la documentación tiene un propósito diferente. Además, como el trabajo se va realizando en pequeñas partes, se necesita menos documentación en cada una de las etapas del proyecto. En lugar de laboriosos documentos formales con una gestión de cambios y un proceso de aprobación rigurosos, los documentos son más cortos y solo necesitan el nivel de detalle suficiente para su propósito. Estos documentos solo incluyen la información necesaria para que el lector conozca qué es lo que tiene que hacer para completar su trabajo, y solo se escriben si son necesarios.

• Los Entregables (Deliverables) configuran el tercer elemento. Los deliverables son los resultados tangibles de un proyecto.
• En los proyectos Waterfall los deliverables se entregan al final del proyecto. La release final del proyecto es un gran evento.
• En cambio, en Agile hay releases más frecuentes y de menor envergadura. Cuando hay mucha incertidumbre en un proyecto, como por ejemplo, en un nuevo mercado o sector Agile permite recibir feedback e ir tuneando el proyecto a medida que se va avanzando. Si se carece de ese feedback es posible entregar al final de un proyecto waterfall algo que el cliente realmente no quiere.

Estas "simples" diferencias marcan un abismo entre la gestión de proyectos Waterfall y Agile

Agile en entornos VUCA

Debemos recordar que Agile se centra en entregar valor en un mundo con altos niveles de incertidumbre, riesgo y competencia. Prepara a los equipos para reaccionar rápidamente cuando cuentan con nueva información, oportunidades de negocio o nuevas tecnologías.

Agile, tal como ya comentamos en otros posts, se adapta mejor para proyectos y sectores que se ven afectados por numerosos cambios o incluso los fomentan ellos mismos. Pero incluso en algunos sectores que podríamos pensar que son bastante estables y que no están sujetos a tantos cambios, podemos encontrarnos con que no son tan fijos y que se ven sometidos a modificaciones, por ejemplo, en regulación, legislación, desastres naturales y otros imprevistos.

Una cosa que nos han enseñado los 2020 y 2021 y concretamente la pandemia de COVID-19, es que ningún sector, industria, empresa, ni persona es inmune al cambio y a la incertidumbre.

 

Y aquí quiero introducir el concepto de VUCA. VUCA es el acrónimo de Volatility (volatilidad), Uncertainty (incertidumbre), Complexity (complejidad) y Ambiguity (ambigüedad). VUCA define las condiciones que afectan a una organización en un mundo complejo y cambiante.

 

Qué significa cada uno de estos conceptos:

• Volatilidad. La velocidad de cambio y rotación en un negocio o situación. En un proyecto de alta volatilidad es importante estar atento a las próximas disrupciones que se puedan producir y cuándo se podrían dar.
• Incertidumbre. La falta de predictibilidad. En un entorno de gran incertidumbre es muy difícil crear planes de futuro que no estén basado en muchas hipótesis que pueden, al final, ser incorrectas.
• Complejidad. El número de fuerzas, problemas, cuestiones, organizaciones y factores que están interrelacionados y que pueden influir en el proyecto.
• Ambigüedad. La posibilidad de malinterpretar las condiciones y las causas de determinados eventos o circunstancias.

Adoptar una metodología Agile incrementa las posibilidades de éxito en los proyectos y los negocios a pesar de la incertidumbre. Para poder hacer una gestión eficiente de los proyectos es necesario entender correctamente el entorno. Cuando iniciamos un proyecto es muy útil examinar el entorno y las condiciones que existen alrededor, antes de decidir cuál es la mejor aproximación para abordar el proyecto.

Si el entorno se puede enmarcar como VUCA entonces es un buen candidato para aplicar Agile, y aunque no es la solución perfecta para solventar la volatilidad, la incertidumbre, la complejidad y la ambigüedad, te ayudará a conseguir los mejores resultados mitigando los riesgos que se presentan, ya que Agile te proporciona herramientas y sistemas para enfrentarte y adaptarte a VUCA.

 

Historia de Agile

Las metodologías Agile aparecen durante la década de los 90. En aquellos años, muchas empresas buscaban una metodología que les permitiese ofrecer al mercado sus productos de forma más rápida y eficiente, adaptándose continuamente a las necesidades de los clientes. En un entorno muy competitivo las empresas además de crear nuevos productos innovadores también deben incorporar la innovación en los procesos, metodologías y formas de trabajo (Ways of Working, WoW) que utilizan para desarrollar sus nuevos productos.

En 2001 los líderes y creadores de algunos de esas nuevas metodologías o procesos se juntaron para establecer unas bases comunes para dichos métodos y de ese modo resolver el problema que muchas de esas empresas tenían para poder desarrollar sus nuevos productos. Ese problema estaba basado en que las empresas estaban tan enfocadas en planificar y documentar sus proyectos, que perdían la visión de lo que realmente importaba, satisfacer las necesidades de los clientes.

Basándose en este insight, los mencionados líderes definieron el Manifiesto Agile para guiar a otros en lo que ellos consideraban que era realmente importante cuando se desarrollaba software, disponer de un proceso flexible y enfocado en las personas (tanto los usuarios de sus productos, como las propias personas que formaban los equipos que creaban esos productos), por encima de los productos finales o los entregables.

Es importante destacar que aunque Agile se definió originalmente para el desarrollo de software, no solo se aplica en proyectos software, sino que sus valores, principios y marcos de trabajo son aplicados y utilizados con éxito en otras muchas industrias. Agile se aplica también en aeronáutica, salud, educación, finanzas, etc. Además, hay que tener en cuenta que los métodos Agile están muy cercanos a los principios de Lean Manufacturing (ideado en 1930 en la factoría de coches de Toyota).

El término Agile hace referencia a moverse de forma rápida y fácil, a flexibilidad y la voluntad y la capacidad de adaptarse rápidamente al cambio. Los proyectos que adoptan una gestión de proyecto Agile utilizan una aproximación iterativa para el desarrollo de los mismos, que implica que los procesos dentro del proyecto se repiten sucesivamente durante el ciclo de vida del proyecto.

Si consideramos Agile en la gestión de proyectos, tenemos Agile Project Management, una forma de llevar a cabo la gestión de proyectos y equipos basada en el Manifiesto Agile, un conjunto de 4 valores y 12 principios que definen la forma de pensar (mindset) que todos los equipos Agile deberían seguir.

Para conseguir esto, el equipo opera en múltiples bloques de tiempo reducido, que se denominan iteraciones. Cada una de esas iteraciones se repite en función del feedback recibido, y en cada una de ellas el equipo aborda un subconjunto de todas las actividades del proyecto y lleva a cabo todo el trabajo requerido para completar ese entregable.

El mundo, los mercados y los usuarios son inciertos, y por tanto impredecibles, y eso implica que en cualquier momento debemos poder adaptarnos a esos cambios que se van produciendo (leer también Agile en entornos VUCA). Esta aproximación iterativa permite al proyecto avanzar rápidamente y a su vez adaptarse a los posibles cambios que puedan aparecer como fruto de esas variaciones y del feedback recibido.

De este modo, el término “Agile” significa flexibilidad, repetición y apertura al cambio durante el proceso, cuando este es necesario. Agile se encarga de recibir feedback del mercado y los clientes con frecuencia de modo que se eviten situaciones habituales con metodologías Waterfall donde la empresa está trabajando en una funcionalidad determinada y cuando la pone en el mercado ha pasado tanto tiempo desde que se definió el producto los cambios que se han producido (en el entorno, en las necesidades del cliente, etc) hacen que la funcionalidad finalmente entregada no es la que el cliente realmente quiere o necesita en el momento actual. Si hay un diálogo más constante y fluido con los clientes es más fácil y rápido reorientar el desarrollo hacia la funcionalidad que realmente es esperada por los clientes, a medida que van viendo el avance.

El mindset Agile también incluye buscar las formas de trabajo más eficientes, adaptando los procesos sin reducir la calidad o el valor del producto desarrollado y para ello la clave es reducir o eliminar todo aquello que no es necesario, tal como aboga Lean. Por tanto, volvemos a ver la sincronía entre Lean y Agile.

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.

Cambiemos a Agile

Cuando se decide hacer la transición hacia Agile es necesario entender qué va a aportarnos esta nueva forma de trabajar en el proyecto o proyectos. La recomendación general es pensar en grande, pero empezar en pequeño y en lugar de hacer un cambio radical en toda la organización, ir paso a paso. Seleccionar aquella organización, equipos y proyectos que consideremos pueden ser más proclives a probar cosas nuevas y que nos permitan experimentar sin poner en riesgo el negocio.

Al abordar este cambio, se puede aplicar una perspectiva similar a lanzar un nuevo producto al mercado. Eso puede ayudar a establecer el marco de actuación. Para ello se puede crear una justificación de negocio antes de iniciar esta nueva andadura. Diseñar un business case tiene sus ventajas, puesto que en caso de ser aceptada la idea, se dejará margen de autonomía a la organización que esté haciendo la implantación, a la vez que se generará expectativa alrededor de los resultados obtenidos, y simplificará la toma de decisión estableciendo unos objetivos claros. Al mismo tiempo, el business case proporciona los criterios para determinar si el proyecto (el cambio a Agile) ha resultado exitoso. En este business case particular, deberemos incluir algunos de los siguientes capítulos:

• Identificar la necesidad: Debemos dejar claro cuál es la situación actual y por qué se plantea la necesidad de cambiar a Agile.
• Definir la oportunidad. Esta necesidad también se puede expresar como una oportunidad o la posibilidad de aportar valor.
• Definir el objetivo: Dejar escrito cuál es el objetivo del cambio de forma de trabajar (de la existente a Agile), es decir, qué queremos conseguir con este cambio. Como ya he comentado en un post anterior, los objetivos se deben definir siguiendo algunas reglas.
• Identificar alternativas. Dentro de Agile, identificar las diferentes opciones que tenemos (Kanban, Scrum, etc).
• Establecer la estrategia: El plan que vamos a seguir para hacer esa transición.
• Definir los hitos. Son los puntos significativos en la transición hacia Agile para verificar el progreso, detectar desviaciones o definir nuevas actuaciones o objetivos adicionales que se vayan definiendo a lo largo del proyecto.
• Cuantificar la inversión. Cuál es el coste de hacer esta migración hacia Agile, qué debemos invertir.
• Calcular el retorno de la inversión. El retorno de la inversión es el resultado y la ganancia obtenidos de este proyecto, en el caso que nos ocupa, la ganancia al evolucionar a Agile.

Con estos elementos claramente identificados es más fácil dar el paso de invertir en esta forma de desarrollar los proyectos, con la posibilidad de ir entregando resultados parciales, hacer un seguimiento intermedio, inspeccionar la evolución y adaptarse a los acontecimientos, para finalmente tener la metodología Agile completamente implantada en la parte de la organización seleccionada. De esta implantación se podrá aprender y adaptarla para nuevas implantaciones.

De esta forma nos planteamos nuestra transición a Agile siguiendo la propia metodología Agile y qué mejor por empezar por uno mismo en el cambio.

Análisis de las Interacciones en un Equipo para Mejorar su Eficiencia

En un post anterior hablaba de las cuatro etapas del desarrollo de los equipos. 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 los puntos fuertes, que merece la pena seguir cultivando, y también los puntos débiles que sobre los que hay que trabajar para mejorar la eficacia de nuestro equipo.

Cuatro Etapas del Desarrollo de los Equipos

Un equipo, antes de conseguir ser eficaz y verdaderamente productivo debe ir evolucionando en su desarrollo, pasando por una serie de etapas, del mismo modo que sucede en el desarrollo de competencias de un individuo, como comenté en un post anterior. También es importante conocer y diagnosticar estas etapas para poder actuar en consecuencia.

Las cuatro etapas en el desarrollo de los equipos son:

1. Orientación (caracterizada por baja productividad/logros y alta satisfacción de los miembros del equipo)
2. Conflicto (nivel de productividad bajo o medio y disminución considerable de la satisfacción de los miembros del equipo)
3. Establecimiento de normas (nivel de productividad medio-alto y satisfacción variable)
4. Producción (nivel de productividad alto y alta satisfacción de los miembros del equipo)

Conocer cada una de las etapas por parte de todos los miembros del equipo ayuda a comprenderla y a que el grupo avance. A continuación voy a detallar un poco más cada una de esas etapas.

1. Etapa de Orientación
He comentado que la productividad es baja y es debido a que los componentes del equipo todavía no tienen clara la meta a conseguir ni las tareas a realizar puesto que inician su andadura como equipo.

Esta etapa se caracteriza por:

• Personalismos. Como el objetivo común y compartido por todos todavía no existe se funciona por intereses propios.
• Expectación. Los individuos del grupo pueden experimentar tensión, incomodidad y cierta ansiedad al desconocer qué se espera de ellos como individuos y como grupo y el papel que deben asumir.
• Dependencia. El desconocimiento de la metodología de trabajo genera inseguridad y tendencia a depender de la figura del responsable del grupo para buscar orientación.
• Formalidad. Las relaciones entre miembros no son fluidas. Al no existir un conocimiento mutuo se adoptan comportamientos muy formales.

Se puede volver a la etapa de Orientación por las siguientes causas, entre otras:

• Cambio en el líder del equipo
• Cambio de una tarea o ampliación de cometidos
• Cambio de algún/algunos de los integrantes del equipo

2. Etapa de Conflicto
Como hemos visto en la etapa anterior predominan los intereses y objetivos personales por lo que aparecen conflictos, que pueden ser explícitos o implícitos. Esta etapa es fundamental, puesto que el hecho de superarla conlleva un reajuste general y esto conducirá al equipo a centrarse en los objetivos del grupo, en lugar de solo hacerlo en los individuales. La resolución de los conflictos es lo que determina la aparición de confianza entre los miembros del equipo.

Además, en esta etapa y la siguiente (establecimiento de normas) los miembros ya son conscientes de las dificultades existentes, tanto para abordar el objetivo propuesto como para concretar y aceptar sus aportaciones y clarificar sus responsabilidades y la manera en que se relacionarán entre ellos, por lo que las energías de los miembros están enfocadas básicamente en resolver estos asuntos, por lo que la satisfacción habrá descendido considerablemente y será variable.

Esta etapa se caracteriza por:

• Posturas individuales y defensa de intereses encontrados
• Competición y rivalidad entre los miembros del equipo
• Alianzas, búsquedas de apoyos y polarización del grupo
• Insatisfacción

3. Etapa de establecimiento de normas
En esta etapa se establecen ciertas normas de funcionamiento de forma expresa o tácitamente, con el fin de centrar al equipo en la tarea e integrar los intereses de sus componentes.

Esta etapa se caracteriza por:

• Organización y distribución del trabajo
• Asunción de la responsabilidad común
• Refuerzo de las relaciones, el "yo" pierde importancia, aparece el "nosotros" y un lenguaje común
• Desaparecen las tensiones. Los conflictos en relación a la tarea se resuelven para asegurar la armonía entre los miembros
• Disminuye la insatisfacción

4. Etapa de producción
En esta etapa el equipo alcanza una alta productividad con un elevado nivel de satisfacción de los miembros del grupo.

Se caracteriza por:

• Relaciones interpersonales fluidas y espontáneas
• Focalización en la tarea
• Satisfacción grupal
• Alto rendimiento

Estas etapas definen la secuencia de progreso habitual, pero puede haber regresiones a etapas anteriores. Por ejemplo, si se intenta evitar el conflicto o no se resuelve (durante la Etapa de Conflicto), no se habrá superado dicha etapa y el conflicto permanecerá latente y puede aparecer en cualquier momento, incluso cuando el equipo está en la Etapa de Producción, lo que supondrá una vuelta atrás importante y una pérdida de productividad considerable. Por ello es importante gestionar las etapas satisfactoriamente para alcanzar un nivel ato de productividad y satisfacción en el equipo.

Gestión de la Presión y la Creatividad

El estrés y la presión temporal por dar resultados tienen efectos complejos en la creatividad.

Hay creencias dispares sobre cómo el estrés y la limitación de tiempo estimulan el pensamiento creativo. Algunos piensan que el efecto es positivo y se estimula la creatividad, mientras que otros piensan que la estrangula.

Sin embargo, algunos estudios (como el que ha llevando a cabo Teresa M. Amabile, cuya entrevista por la Harvard Business School se puede ver en el artículo "Time Pressure and Creativity: Why Time is Not on Your Side", http://hbswk.hbs.edu/item/3030.html#related#related) indican que para conseguir no estrangular la creatividad hay que situar la presión por los plazos en una zona intermedia entre no tener ninguna presión y tener demasiada. Esto que puede parecer obvio no se había podido concluir en estudios llevados a cabo anteriormente por otros investigadores, tal como cita la propia Teresa en la entrevista.

Teniendo en cuenta que debe haber un balance entre mucha y poca presión, los líderes y managers deberían procurar que las personas de sus equipos se encontrasen en esa franja intermedia para lograr los mejores resultados.

El artículo indica que el exceso de presión dificulta la creatividad por lo que debería ser evitado, pero si no hay forma de impedir que esos plazos planeen sobre el equipo, el responsable debe "protegerlo" eliminando las distracciones y reforzando el sentimiento de estar haciendo algo difícil pero importante, en definitiva cumpliendo una misión. Sin embargo está claro que no se puede trabajar en modo presión por un plazo de tiempo muy largo sin llegar a agotarse.

En el otro extremo, si hay muy poca presión, la gente tiende a acomodarse, a no esforzarse, a bajar el ritmo (seguramente todos hemos comprobado esto en nuestra época de estudiantes). En estas condiciones un líder debe animar a la gente a ser más creativa y proponer nuevos retos. En definitiva, debe volver a poner a su equipo en esa zona con un nivel aceptable de presión para que trabajen en un estado de estimulación.

En definitiva, los responsables de los equipos deben actuar para eliminar los obstáculos que dificultan la creatividad y posicionar a las personas de su equipo en el punto óptimo para conseguir resultados. Ese punto óptimo, obviamente, dependerá de cada persona, por lo que habrá que determinarlo individualmente.