¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.techbiz
Pedro Revueltas 11/09/2019 Cargando comentarios…
Si alguna vez has trabajado en un equipo de desarrollo software, o en cualquier equipo que comparta una visión y luche, cada día, codo con codo, por alcanzarla, habrás vivido conflictos por decenas.
Sin embargo, ¿conoces herramientas para tratar los conflictos? O ¿simplemente te vales de tu simpatía y “saber hacer” para escapar airoso?
Voy más allá, ¿conoces las prácticas que ofrece el mundo del agilismo para abordarlos?, ¿sabes quién es responsable de solucionar los conflictos?, ¿piensas que es el Scrum Master?
Como Nexus Scrum Master, viví una situación complicada en un equipo con escalado y me di cuenta de que ni yo tenía el conocimiento necesario para abordar los conflictos ni tampoco había enseñado al resto del equipo las herramientas necesarias para tratarlos.
Reconocido el error, me puse manos a la obra y me gustaría compartir en este post lo aprendido, que fundamentalmente se basa en el modelo de Thomas-Kilmann y en el libro ‘Coaching Agile Teams’, de Lyssa Adkins.
Las relaciones entre los miembros de un equipo de desarrollo son relaciones íntimas. A veces, incluso podrían tener similitudes con las relaciones de pareja. Pasamos muchas horas juntos en las trincheras, discutimos sobre tecnologías, sobre soluciones... nos divertimos.
Pero también debemos hacer entregas, a veces, en fechas cerradas, o resolver incidencias en producción, bajo presión, donde tenemos poco tiempo para tomar decisiones y ejecutarlas.
Cuando las relaciones entre personas son íntimas debemos aceptar que surgen conflictos. Los conflictos en los equipos son naturales, a veces inevitables y debemos aceptarlos.
A partir de aquí, si somos inteligentes, aprenderemos cómo manejarlos y cómo transformarlos en una oportunidad para mejorar, convirtiendo el conflicto en algo positivo (por contraposición, un conflicto mal gestionado será un conflicto negativo y mermará el rendimiento del equipo).
En los equipos ágiles estamos obsesionados con mejorar (kaizen, retrospectivas, etc.), así que debemos ver el conflicto como una oportunidad para “inspeccionar(nos) y adaptar(nos)”.
La primera pregunta que surge es: en un equipo ágil, ¿quién es responsable de resolver los conflictos?, ¿el Agile Coach?, ¿el Scrum Master? Si un conflicto se convierte en un impedimento para el equipo, entonces ¿es responsabilidad del Scrum Master eliminar el impedimento?
Según Lyssa Adkins, autora del libro Coaching Agile Teams, el Agile Coach (o el Scrum Master) es responsable de enseñar al equipo de desarrollo cómo abordar los conflictos, pero son los miembros del equipo quienes son responsables de resolverlos. Lógico, si los equipos ágiles son auto-organizados, ellos mismos deben resolver sus conflictos.
El papel del Agile Coach es hacer cuanto esté en su mano para enseñar al equipo herramientas, prácticas, técnicas… que les permita, primero, evitar la aparición de los mismos (veremos algunas técnicas más abajo) y, segundo, cuando surjan, abordarlos de una manera constructiva, positiva, como una oportunidad para mejorar algo.
El papel de los miembros del equipo de desarrollo es utilizar las prácticas aprendidas para abordar los conflictos y resolverlos. ¿Todos los conflictos? Todos no. Casi todos.
Hay conflictos que, o bien son irresolubles o bien es mejor dejarlos porque sabemos que con el tiempo se van a solucionar “solos” (por ejemplo, por cambios que se llevan a cabo desde otros niveles de la organización, por movimientos de personas, etc).
Lo importante es que cada miembro del equipo es responsable de solucionar sus conflictos, no el Agile Coach o el Scrum Master.
Los modos de respuesta que propone Lyssa Adkins en su libro son tres:
Es de decir, realmente propone dos modelos, puesto que el tercero consiste en revelar los dos primeros al equipo, para que éste pueda avanzar hacia la auto-organización también en el tratamiento de conflictos.
Este modo de respuesta se basa en identificar el nivel del conflicto y, en base al mismo, decidir qué estrategia seguir.
Como puedes imaginar, no existe ninguna norma internacional que clasifique los niveles de conflictos. Lyssa Adkins propone un modelo desarrollado hace ya unos años por Speed B. Leas, publicado en su libro ‘Discover Your Conflict Management Style’.
Este modelo tiene su origen en el ámbito de las corporaciones religiosas (donde los equipos también tienen relaciones muy intensas), pero esa es otra historia.
El modelo de Speed B. Leas define 5 niveles de conflictos:
La clave para identificar el nivel de un conflicto consiste en observar, conversar y centrar la atención en el lenguaje. Atender a cómo se expresan las partes del conflicto nos puede dar pistas del nivel en el que se encuentran.
Nota: para más detalles, puedes leer el siguiente artículo publicado en el PMI Coaching agile teams to constructively navigate conflict con ejemplos de lenguaje durante las conversaciones.
Una vez que has identificado el nivel, puedes decidir qué estrategia seguir:
En este nivel podemos usar dos técnicas muy sencillas para avanzar hacia la toma de decisiones:
Como curiosidad, este modelo de resolución de conflictos a su vez está inspirado en el Modelo de Thomas-Kilmann, que clasifica las estrategias para solucionar los conflictos en función de dos variables: la asertividad y la cooperación:
El modelo de Thomas-Kilmann muestra dos estrategias más, además de las que Lyssa Adkins promulga. Son la Competencia y la Evitación.
Las Estructuras son un modelo de respuesta mucho más poderoso que el de “Analizar y Responder” que acabamos de ver. Las Estructuras se basan en la siguiente idea: para solucionar conflictos en equipos ágiles muchas veces es mejor centrarse en mejorar el rendimiento del equipo que en mejorar las relaciones personales.
Es decir, en lugar de atender el problema concreto, bajas un nivel, y utilizas los fundamentos del agilismo, los principios y valores, las buenas prácticas, para dar una solución al problema en el contexto del agilismo.
El concepto de Estructura se ilustra fácilmente con un ejemplo.
Supongamos que Juan está harto de Luis porque éste siempre escribe un código “cogido con pinzas”, haciendo el mínimo esfuerzo por terminar las tareas, y luego Juan tiene que refactorizar el código de Luis antes de subir el incremento a producción.
En este caso, en lugar de entrar en un debate subjetivo acerca de qué es un código “cogido con pinzas” frente a la calidad que Juan piensa que debe tener ese código podemos crear la siguiente Estructura: un póster, visible a todo el equipo, que muestre el DoD (Definition of Done) acordado, consensuado y revisable, por el equipo.
El DoD debe incluir todo aquello que el equipo piense que debe tener un elemento para considerarse hecho, incluyendo requisitos no funcionales relativos a la calidad y la seguridad.
Es decir, el lugar de tratar el conflicto de manera aislada entre Juan y Luis hablando de calidad relativa, recuperas el DoD en el contexto de todo el equipo, incluyendo los requisitos de calidad consensuados por todo el equipo.
Como puedes suponer, las Estructuras pueden tener cualquier soporte: poster, collage, calendario, gráficos... Son cualquier cosa que nos permita abordar los conflictos a la vez que reforzamos los fundamentos del agilismo. Por eso son tan poderosas, porque nos ayudan a evitar otros conflictos relacionados con un pobre rendimiento, a la vez que refuerzan la base de agilismo del equipo.
Es decir, las Estructuras no responden a un modelo analítico, como vimos que hacía el modo de respuesta “Analiza y Responde”, sino que son creativas, flexibles y heterogéneas. El principal elemento que las define es que se basan en los fundamentos del agilismo para guiar al equipo durante la navegación de un conflicto.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.