Como los Scrum Masters Resuelven Conflictos: El Enfoque del Lider Servidor

Q: ¿En que se diferencia la resolucion de conflictos en Scrum de la gestion de conflictos en la gestion de proyectos tradicional?

En la gestion de proyectos tradicional, la resolucion de conflictos tipicamente fluye a traves de una cadena jerarquica - el director del proyecto escala a un gerente funcional quien toma una decision. En Scrum, el modelo de lider servidor significa que el Scrum Master facilita la propia resolucion del equipo en lugar de imponer decisiones. El objetivo no es solo solucionar el problema inmediato sino desarrollar la capacidad del equipo para manejar futuros conflictos de forma independiente. Este enfoque descentralizado significa que los equipos Scrum que dominan la resolucion de conflictos se vuelven cada vez mas auto-organizados con el tiempo.

Q: ¿Puede un Scrum Master ser demasiado neutral durante un conflicto? ¿Cuando es apropiado abogar por un resultado especifico?

Si - la sobre-neutralidad es un modo de fallo real. Un Scrum Master deberia abogar firmemente cuando se estan violando los valores Scrum (coraje, apertura, respeto), cuando el cumplimiento o la seguridad estan en juego, o cuando el comportamiento de una parte impide que otros hablen libremente. La distincion clave es entre abogar por un resultado de proceso (como se desarrolla la conversacion) versus un resultado de contenido (que funcionalidad se construye). Los Scrum Masters pueden y deben intervenir en el proceso; deben permanecer neutrales en las decisiones de contenido que pertenecen al equipo o al Product Owner.

Q: ¿Como deberia manejar un Scrum Master el conflicto con un Product Owner que cronicamente anula las decisiones de los Desarrolladores sobre el enfoque tecnico?

Este es un conflicto estructural de Scrum enraizado en limites de roles malentendidos. El Product Owner es dueno de lo que se construye (el backlog y las prioridades), mientras que los Desarrolladores son duenos de como se construye (enfoque tecnico y arquitectura). El Scrum Master deberia facilitar una conversacion educativa con el Product Owner sobre este limite, usando la Guia Scrum como referencia. Si el comportamiento continua, se convierte en un impedimento organizacional que requiere escalada a la gerencia, ya que un Product Owner que microgestiona las decisiones tecnicas socava la capacidad del equipo para auto-organizarse.

Q: ¿Como afecta el tamano del equipo a la dinamica del conflicto en Scrum, y cambia el enfoque optimo de resolucion de conflictos para equipos mas grandes?

Scrum recomienda equipos de 10 o menos por una buena razon - los equipos mas pequenos tienen menos permutaciones interpersonales y por lo tanto una complejidad de conflicto de base mas baja. En equipos mas grandes o entornos escalados (usando marcos como SAFe, LeSS o Nexus), el conflicto puede ocurrir tanto dentro de los Equipos Scrum como entre ellos. El conflicto entre equipos a menudo requiere escalada al nivel de Scrum de Scrums o de un Chief Product Owner. Los principios del lider servidor permanecen iguales, pero las organizaciones mas grandes necesitan protocolos de conflicto mas explicitos, marcos de derechos de decision y procesos de gestion de dependencias entre equipos.

Q: ¿Como contribuye la deuda tecnica al conflicto del equipo, y cual es el rol del Scrum Master para abordarla?

La deuda tecnica es una fuente cronica de conflicto en los equipos Scrum porque crea desacuerdo entre la presion para entregar nuevas funcionalidades (perspectiva del Product Owner) y la necesidad de abordar la calidad subyacente del codigo (perspectiva del Desarrollador). Los equipos con alta deuda tecnica frecuentemente experimentan un aumento de disputas de estimacion, frustracion durante las retrospectivas y trabajo oculto que altera los compromisos del Sprint. El rol del Scrum Master es hacer visible la deuda tecnica - ayudando al equipo a cuantificar su impacto y facilitando conversaciones con el Product Owner sobre el equilibrio entre la reduccion de la deuda y la entrega de nuevas funcionalidades. Un backlog de deuda tecnica visible evita conflictos recurrentes al mantener el intercambio transparente.

Q: ¿Como deberia abordar un Scrum Master el conflicto entre miembros del equipo de diferentes culturas con diferentes normas de comunicacion?

Las diferencias culturales en la directness, la jerarquia y las normas de desacuerdo son una fuente significativa de malentendidos en equipos diversos. Lo que un miembro del equipo lee como asertividad normal, otro puede experimentarlo como agresion o falta de respeto. El Scrum Master deberia facilitar proactivamente una conversacion de calibracion cultural temprana en la formacion del equipo, pidiendo a cada miembro que comparta como prefiere expresar y recibir el desacuerdo. Construir normas explicitas del equipo que reconozcan los diferentes estilos de comunicacion previene muchos conflictos interculturales. Cuando surjan malentendidos culturales, el Scrum Master deberia nombrar la dinamica explicitamente y crear espacio para la curiosidad en lugar del juicio.

Q: ¿Como puede un Scrum Master recien certificado sin entrenamiento en mediacion desarrollar habilidades de resolucion de conflictos en la practica?

La resolucion de conflictos es una habilidad aprendible que se desarrolla mediante la practica deliberada. Los nuevos Scrum Masters deben empezar por observar en lugar de intervenir de inmediato - desarrollando reconocimiento de patrones para los tipos de conflicto antes de intentar la facilitacion. Tomar un curso estructurado de mediacion o facilitacion (como los ofrecidos por organizaciones como el Centro para la Resolucion de Conflictos) proporciona habilidades fundamentales mas alla de lo que cubre la certificacion Scrum. Practicar primero en situaciones de bajo riesgo, buscar retroalimentacion de los miembros del equipo despues de la facilitacion y reflexionar sobre lo que funciono en un diario acelera el desarrollo de habilidades. Encontrar un mentor o coach con amplia experiencia en facilitacion de equipos es uno de los aceleradores mas efectivos.

Q: ¿Pueden los equipos Agiles de alto rendimiento tener conflictos frecuentes, o el alto rendimiento significa bajo conflicto?

Los equipos Agiles de alto rendimiento frecuentemente tienen MAS conflicto abierto que los equipos promedio, no menos. La diferencia es que su conflicto esta centrado en tareas (sobre ideas, enfoques y prioridades) en lugar de en las relaciones (personal, politico o pasivo-agresivo). La investigacion de Patrick Lencioni muestra que los equipos dispuestos a participar en conflictos productivos toman mejores decisiones, sacan los riesgos a la superficie mas temprano y logran un mayor compromiso con los resultados compartidos. El objetivo para un Scrum Master no es un equipo libre de conflictos sino un equipo capaz de conflictos - uno que pueda disentir vigorosamente sobre ideas y aun asi emerger con un fuerte compromiso compartido para la accion.

Q: ¿Como se conecta la resolucion de conflictos con las practicas de DevOps y entrega continua en los equipos Scrum?

Las practicas de DevOps crean zonas de conflicto especificas entre los equipos de desarrollo y operaciones en torno a la frecuencia de despliegue, la tolerancia al riesgo de cambio y las responsabilidades de guardia. Los Scrum Masters en entornos DevOps necesitan facilitar conversaciones que tiendan puentes entre las diferencias culturales entre la cultura de desarrollo 'moverse rapido' y la cultura de operaciones 'la estabilidad primero'. Las herramientas concretas que reducen el conflicto DevOps incluyen revisiones conjuntas de incidentes (post-mortems sin culpa), rotaciones de guardia compartidas que construyen empatia mutua, elementos de definicion de hecho que incluyen explicitamente criterios de preparacion operacional y tecnicas de entrega progresiva (lanzamientos canarios, banderas de funcionalidades) que reducen el riesgo percibido del despliegue frecuente.

Q: ¿Cual es la responsabilidad del Scrum Master cuando un conflicto involucra a un miembro de la alta direccion o a un ejecutivo de las partes interesadas?

Los conflictos que involucran a ejecutivos o lideres senior requieren una navegacion cuidadosa porque los desequilibrios de poder posicional pueden suprimir el dialogo honesto. El Scrum Master deberia evitar confrontar directamente a los altos cargos frente al equipo, lo que arriesga crear una crisis politica. En cambio, plantear las preocupaciones uno a uno con el ejecutivo primero, encuadrandolas en torno al impacto en la entrega del equipo y la efectividad de Scrum. Si el ejecutivo esta socavando la estructura Scrum (p. ej., pasando por alto al Product Owner, haciendo demandas directas a los Desarrolladores), esto es un impedimento sistemico que requiere escalada a quien en la organizacion tenga autoridad sobre la transformacion agil. Documentar comportamientos especificos y sus impactos en la entrega para hacer la conversacion factual en lugar de personal.

Por Abhay Talreja

12/5/2026

Mi último artículo - Empirical Process Control - The Key to Agile Success

Resolucion de Conflictos en Equipos Scrum: Enfoque del Lider Servidor

El Scrum Master no es un gerente que ordena a las personas que dejen de discutir. Como lider servidor, el Scrum Master crea las condiciones donde el conflicto puede salir a la superficie de manera segura, abordarse de forma constructiva y convertirse en un motor del crecimiento del equipo.

El conflicto dentro de los equipos Scrum no solo es inevitable - es saludable cuando se maneja bien. Los equipos multifuncionales con perspectivas diversas van a estar en desacuerdo. La pregunta nunca es si surgira el conflicto, sino si el equipo tiene las habilidades y el entorno para resolverlo de forma productiva.

💡

El conflicto no gestionado le cuesta a las organizaciones aproximadamente 2,8 horas por empleado por semana segun la investigacion de CPP Inc. Los Scrum Masters que construyen practicas solidas de resolucion de conflictos protegen tanto la moral del equipo como la velocidad del Sprint.

La resolucion efectiva de conflictos requiere una comprension profunda del comportamiento humano, los modos de conflicto Thomas-Kilmann, los principios de seguridad psicologica y las habilidades de facilitacion para guiar a un equipo desde la friccion hasta la resolucion.

Esta guia cubre cada dimension de la resolucion de conflictos que necesita un Scrum Master - desde comprender los tipos de conflicto hasta aplicar el modo de intervencion correcto, gestionar la escalada y construir una cultura de equipo lo suficientemente resiliente para manejar el desacuerdo sin descarrilar la entrega.

Respuesta Rapida: Resolucion de Conflictos en Scrum de un Vistazo

Aspecto	Detalles
Rol Principal del Scrum Master	Facilitador neutral y lider servidor - no un juez ni un gerente
Conflicto Saludable vs. No Saludable	Saludable: debate centrado en tareas que mejora los resultados. No saludable: ataques personales, evitacion, juegos de poder
Modo Mas Efectivo (por defecto)	Colaborar (alta asertividad + alta cooperatividad)
Cuando Usar el Modo Competir	Problemas de seguridad, violaciones eticas o decisiones criticas en el tiempo
Umbral de Escalada	Escalar a RRHH/gerencia cuando hay problemas de seguridad personal, legales o cuando la resolucion no se logra repetidamente
Requisito Fundamental	Seguridad psicologica - los miembros del equipo deben sentirse seguros para disentir sin temor a ser castigados
Marco Clave	Instrumento de Modos de Conflicto Thomas-Kilmann (TKI): 5 modos en dos dimensiones

Tabla de Contenidos-

Comprendiendo el Conflicto en los Equipos Scrum

Conflicto Saludable vs. No Saludable

No todos los conflictos son iguales. El primer trabajo del Scrum Master es distinguir el desacuerdo productivo de la disfuncion destructiva.

Conflicto Saludable:

Se centra en tareas, ideas, enfoques o prioridades
Produce mejores resultados que las posiciones originales de cualquier persona
Deja a los participantes sintiendose escuchados y respetados, incluso cuando no estan de acuerdo
Saca a la superficie suposiciones y riesgos ocultos tempranamente, antes de que se conviertan en bloqueadores del Sprint
Ejemplo: Los Desarrolladores debaten si usar REST o GraphQL para una nueva integracion, eligiendo finalmente la mejor opcion mediante evidencia y discusion

Conflicto No Saludable:

Se vuelve personal - ataca el caracter, la motivacion o la competencia en lugar de las ideas
Se evita por completo, llevando la tension al subterraneo donde se enquista
Crea ganadores y perdedores en lugar de soluciones compartidas
Lleva a la conformidad pasiva sin compromiso genuino
Ejemplo: Un desarrollador deja de compartir preocupaciones porque la ultima vez que lo hizo, el Scrum Master las descarto

⚠️

Las "Cinco Disfunciones de un Equipo" de Patrick Lencioni identifica el miedo al conflicto como la segunda disfuncion, que surge directamente de la ausencia de confianza. Los equipos que evitan el conflicto crean armonia artificial, no alineacion real.

Fuentes Comunes de Conflicto en Equipos Agiles

El entorno colaborativo y autonomo de Scrum amplifica tanto la frecuencia como la visibilidad de los desacuerdos. Las fuentes comunes incluyen:

Ambiguedad de roles: Limites poco claros entre la autoridad del Product Owner y la toma de decisiones de los Desarrolladores
Presion de velocidad: Los compromisos del Sprint crean estres que reduce la paciencia y la empatia
Desacuerdos tecnicos: Decisiones de arquitectura, estandares de calidad del codigo, compensaciones de deuda tecnica
Disputas de prioridad: Desacuerdos entre las decisiones de backlog del Product Owner y las preferencias tecnicas de los Desarrolladores
Choques de personalidad: Diferentes estilos de comunicacion, habitos de trabajo o enfoques para resolver problemas
Contribucion desigual: Percepcion de que algunos miembros del equipo cargan con mas trabajo que otros
Interferencia organizacional: Gerentes o partes interesadas externas que evitan la estructura Scrum
Brechas en la Definicion de Hecho: Miembros del equipo con diferentes estandares de calidad no declarados

El Costo del Conflicto No Resuelto

Dejar los conflictos sin resolver tiene costos que se acumulan:

La velocidad cae a medida que la colaboracion se rompe
La seguridad psicologica se erosiona, reduciendo la transparencia en los Scrums Diarios
Los miembros del equipo con talento se desconectan o se van
La calidad del producto sufre cuando las revisiones y retrospectivas honestas se vuelven una actuacion
La confianza de las partes interesadas disminuye cuando la entrega se vuelve impredecible

Los Modos de Conflicto Thomas-Kilmann

Desarrollado por Kenneth Thomas y Ralph Kilmann en 1974, el Instrumento de Modos de Conflicto Thomas-Kilmann (TKI) sigue siendo el marco mas ampliamente utilizado para comprender como los individuos y los equipos responden al conflicto. Mapea cinco modos en dos dimensiones: asertividad (grado en que uno persigue sus propios intereses) y cooperatividad (grado en que uno satisface los intereses de la otra parte).

Cinco Modos Explicados

Modo	Asertividad	Cooperatividad	Mejor Aplicacion en Scrum
Colaborar	Alta	Alta	Debates de arquitectura tecnica, negociaciones de Definicion de Hecho
Competir	Alta	Baja	Violaciones eticas, problemas de seguridad, cumplimiento no negociable
Comprometerse	Moderada	Moderada	Ajustes de alcance del Sprint cuando el tiempo es limitado
Acomodar	Baja	Alta	Cuando la otra parte tiene mas experiencia o el problema es menor
Evitar	Baja	Baja	Dejar que las emociones se enfrien antes de revisar un tema delicado

Colaborar es el modo predeterminado para los lideres servidores. Trata el conflicto como un rompecabezas que se resuelve juntos, no como una batalla que ganar. Requiere mas tiempo pero produce acuerdos duraderos y fortalece las relaciones del equipo.

Competir deberia ser raro para los Scrum Masters. Su rol es de facilitacion, no de autoridad. Sin embargo, cuando el comportamiento de un miembro del equipo viola la seguridad psicologica de otros (intimidacion, acoso, exclusion deliberada), el Scrum Master debe competir - trazando una linea firme.

Comprometerse es una herramienta realista cuando los plazos crean restricciones genuinas. Ambas partes ceden algo. El riesgo es que las soluciones de compromiso pueden no satisfacer plenamente a nadie - uselo cuando la colaboracion no es posible dentro del tiempo disponible.

Acomodar es apropiado cuando reconoce que la posicion de la otra parte es genuinamente mejor, o cuando la relacion importa mas que el resultado especifico. El uso excesivo lleva al resentimiento y la supresion de preocupaciones validas.

Evitar tiene usos legitimos: permitir que las emociones acaloradas se asienten, decidir que un problema no vale el costo energetico, o esperar mejor informacion. La evitacion cronica, sin embargo, es disfuncional y es una senal de baja seguridad psicologica.

💡

El hallazgo de la investigacion TKI de que el 80% del comportamiento de manejo de conflictos esta moldeado por los sistemas organizacionales y la cultura - no la personalidad individual - significa que la palanca mas poderosa del Scrum Master es el diseno del entorno, no el coaching individual.

Elegir el Modo Correcto

Haga estas preguntas antes de seleccionar un modo de conflicto:

¿Que tan urgente es la resolucion? La alta urgencia favorece Competir o Comprometerse sobre Colaborar.
¿Que tan importante es la relacion a largo plazo? La alta importancia favorece Colaborar o Acomodar.
¿Quien tiene la experiencia mas relevante? La deferencia (Acomodar) tiene sentido cuando la otra parte sabe demostrablemente mas.
¿Cuales son las apuestas? Las decisiones de alto riesgo justifican la inversion en Colaborar. Los problemas de bajo riesgo pueden Evitarse.
¿Hay un desequilibrio de poder? Competir con alguien que carece de poder posicional para responder es coercitivo, no asertivo.

El Proceso de Resolucion de Conflictos del Lider Servidor

El Scrum Master no impone soluciones. Facilita la propia capacidad del equipo para resolver el conflicto. Aqui esta el proceso de cinco pasos:

Paso 1: Reconocer y Crear Seguridad

Nombre el conflicto explicitamente y sin juicio. El silencio senala aceptacion tacita de la disfuncion.

Diga lo que observa, no lo que juzga: "Note tension en la Planificacion del Sprint de ayer cuando discutimos el enfoque de diseno de la API. Me gustaria que lo abordemos directamente."
Separe el conflicto de las personas: "Tenemos un desacuerdo sobre el enfoque, no un problema entre nosotros."
Establezca reglas basicas para la conversacion: hablar por uno mismo (usar declaraciones "Yo"), atacar ideas no personas, escuchar para entender no para responder.

Paso 2: Recopilar Perspectivas Individualmente

Antes de reunir a las partes, entienda cada perspectiva de forma privada. Esto evita las posturas publicas y permite que las personas hablen con franqueza.

Reunase con cada parte por separado
Haga preguntas abiertas: "¿Que resultado necesita de esta situacion?" "¿Cual es la preocupacion raiz detras de su posicion?"
Escuche sin tomar partido ni ofrecer soluciones prematuras
Busque intereses subyacentes debajo de las posiciones declaradas (el concepto de negociacion de "Obtenga el Si" de Fisher y Ury)

Paso 3: Facilitar la Resolucion Conjunta de Problemas

Reunir a las partes con estructura que evite que la conversacion se degrade.

Resumir lo que escucho de cada parte (neutralmente) antes de que nadie responda
Pedir a cada parte que reformule la posicion de la otra en sus propias palabras - esto construye empatia
Redirigir desde posiciones ("Quiero la Funcionalidad X primero") a intereses ("Necesito mostrar al cliente valor medible antes de fin de trimestre")
Generar multiples opciones antes de evaluar cualquiera de ellas - cantidad primero, calidad despues

Paso 4: Acordar una Solucion y Comprometerse

Un conflicto resuelto necesita compromiso explicito, no consenso vago.

Enunciar la solucion acordada claramente y hacer que todas las partes confirmen su comprension
Asignar responsabilidad donde se necesite accion
Documentar en un tablero de Retrospectiva o documento de acuerdo de equipo
Si no se llega a un acuerdo completo, usar un metodo de toma de decisiones estructurado (votacion por puntos, puno a cinco, toma de decisiones por consentimiento)

Paso 5: Hacer Seguimiento y Reforzar

La resolucion de conflictos no es un evento unico. La confianza se reconstruye a traves del cumplimiento consistente.

Hacer seguimiento en el proximo Scrum Diario o retrospectiva sobre como se esta manteniendo el acuerdo
Reconocer y valorar cuando el equipo navega bien el desacuerdo
Sacar a la superficie cualquier retroceso temprano antes de que los patrones se restablezcan

Escenarios de Conflicto en los Eventos Scrum

Conflicto en la Planificacion del Sprint

Conflicto comun: Desacuerdo entre el Product Owner y los Desarrolladores sobre cuantos elementos caben en el Sprint.

Respuesta del lider servidor:

Facilitar una conversacion basada en la capacidad usando datos reales de velocidad en lugar de opiniones
Recordar al equipo que los Desarrolladores son duenos del pronostico del Sprint, no el Product Owner
Ofrecer poner en caja de tiempo el debate: "Acordemos en los proximos 10 minutos o pospongamos los elementos de menor prioridad"

Conflicto en el Scrum Diario

Conflicto comun: Un Desarrollador senala publicamente el comportamiento bloqueador de otro, creando verguenza.

Respuesta del lider servidor:

Redirigir el Scrum Diario a su proposito: plan de 15 minutos para las proximas 24 horas
Programar una reunion separada para abordar el problema subyacente
Instruir a ambas partes despues del evento sobre la diferencia entre problemas de bloqueo (para el Scrum Diario) y preocupaciones interpersonales (para una conversacion separada)

Conflicto en la Revision del Sprint

Conflicto comun: Las partes interesadas rechazan fuertemente las funcionalidades entregadas, y los Desarrolladores sienten que su trabajo esta siendo descartado.

Respuesta del lider servidor:

Facilitar retroalimentacion estructurada: distinguir entre "esto no cumple los Criterios de Aceptacion" (valido) y "cambiamos de opinion sobre lo que queremos" (conversacion a nivel de backlog)
Proteger a los Desarrolladores de criticas personales mientras se mantiene espacio para retroalimentacion genuina del producto
Recordar a las partes interesadas que la Revision del Sprint es para inspeccion y adaptacion, no para aprobacion o culpa

Conflicto en la Retrospectiva

Conflicto comun: Una retrospectiva se convierte en una sesion de culpas dirigida a un miembro del equipo.

Respuesta del lider servidor:

Invocar la Directiva Principal: "Creemos que todos hicieron el mejor trabajo posible dado lo que sabian en ese momento"
Cambiar de la culpa ("El siempre hace esto") a la indagacion sistemica ("¿Que condiciones hicieron que esto fuera mas probable que sucediera?")
Si es necesario, pausar la retrospectiva y reprogramarla con un formato de facilitacion mas estructurado

Seguridad Psicologica: La Base del Conflicto Saludable

La investigacion de Amy Edmondson sobre la seguridad psicologica la identifica como el predictor mas fuerte de equipos de alto rendimiento. Sin ella, los miembros del equipo suprimen preocupaciones, ocultan errores y cumplen en la superficie en lugar de participar genuinamente.

💡

La investigacion del Proyecto Aristotle de Google descubrio que la seguridad psicologica era el factor numero 1 que distinguia a sus equipos de mayor rendimiento de los promedio - mas importante que el talento individual, la claridad de objetivos o la composicion del equipo.

El rol del Scrum Master en la construccion de seguridad psicologica:

Modelar la vulnerabilidad: Admitir los propios errores e incertidumbres abiertamente
Responder constructivamente a las malas noticias: Reaccionar a los problemas con curiosidad ("¿Que paso? ¿Que aprendimos?") no con culpa
Invitar explicitamente a la disidencia: "¿Quien tiene una perspectiva diferente?" "¿Que no estamos viendo aqui?"
Cumplir de manera consistente: La seguridad se destruye cuando se plantean preocupaciones y luego se ignoran o castigan
Proteger las voces minoritarias: Sacar activamente a los miembros mas callados del equipo antes de que las voces dominantes llenen todo el espacio

Senales de baja seguridad psicologica en un equipo Scrum:

Las retrospectivas producen solo observaciones superficiales
Los Scrums Diarios no reportan impedimentos incluso cuando el equipo claramente esta luchando
Los desacuerdos se callan cuando el Product Owner entra al cuarto
Los miembros del equipo estan de acuerdo publicamente y se quejan privadamente
Nadie cuestiona las estimaciones incluso cuando parecen poco realistas

Construyendo seguridad paso a paso:

Ejecutar un "experimento seguro para fallar" - probar algo pequeno con permiso explicito para fallar
Nombrar y apreciar los momentos en que los miembros del equipo hablan sobre riesgos
Usar herramientas de retrospectiva anonimas (Miro, FunRetro) para reducir las apuestas sociales de la retroalimentacion honesta
Establecer normas explicitas del equipo sobre el desacuerdo: "Esperamos el debate. Nos comprometemos una vez que decidimos."

Escenarios de Conflicto Especificos por Industria y Respuestas

Equipo de SaaS / Servicios en la Nube

Escenario de conflicto: Los desarrolladores de backend y frontend no estan de acuerdo en la estrategia de versionado de la API, creyendo ambos que su enfoque es arquitectonicamente superior.