Cómo una empresa belga de reparto se transformó con Scrum

Cuando una empresa belga de mensajería postal y de paquetería decidió experimentar con Scrum, no lo hizo persiguiendo palabras de moda, sino buscando una forma de liberarse de las entregas tardías, la elevada deuda técnica y una frustrante desconexión entre negocio y TI.
El producto en cuestión era Tracked Mail, un servicio crítico que daba soporte a dos grandes áreas de negocio: Operaciones de Correo y Grandes Cuentas.

El camino no fue sencillo. Los primeros Sprints dejaron a la dirección preguntándose si se habían equivocado. Pero, en 18 meses, una combinación de cambios estructurales, mayor colaboración y una firme apuesta por la calidad transformó Tracked Mail en uno de los equipos de producto más fiables de la organización.

Así es como sucedió —y lo que puedes aprender de ello.

La configuración inicial dividió a los desarrolladores de Tracked Mail en dos equipos de unas 11 personas cada uno, alineados con sus respectivas áreas de negocio.

• Un Product Owner (de TI) coordinaba las prioridades con ambos responsables de negocio.
  
  
• Un Scrum Master (un coach ágil) daba soporte a ambos equipos.
  
  

Desde un punto de vista técnico, esta separación tenía sentido: ciertas aplicaciones eran exclusivas de cada unidad. Sin embargo, los dos primeros Sprints apenas entregaron resultados. El cambio de flujo de trabajo destapó problemas de fondo que se habían ocultado con el proceso anterior.

Lección: Las caídas iniciales de productividad son normales al adoptar Scrum. Suelen revelar problemas ocultos que hay que abordar antes de lograr avances reales.

Uno de los movimientos más impactantes al inicio fue invitar a los principales stakeholders de negocio a las Retrospectivas de Sprint. Al principio, la dirección dudaba de su valor, pero estas sesiones ofrecieron una visión cruda y sin filtros de los retos que afrontaban los desarrolladores:

• Alta deuda técnica tras años de “parches” rápidos.
  
  
• Malas prácticas de ingeniería por falta de tiempo y herramientas.
  
  
• Procesos lentos y rígidos.
  
  
• Equipos responsables pero sin capacidad de decisión.
  
  

Lección: La interacción directa y regular entre desarrolladores y responsables de negocio genera empatía y una propiedad compartida de los problemas.

Para ganar confianza y capacidad, los equipos acordaron:

• Dedicarse durante un Sprint a instalar nuevas herramientas para mejorar las prácticas de ingeniería.
  
  
• Reservar el 10% de cada Sprint para mejora continua.
  
  
• Asignar a los responsables de negocio para que trabajaran codo a codo con los desarrolladores durante el Sprint.
  
  
• Involucrar la arquitectura empresarial para simplificar el panorama de aplicaciones.
  
  

En el Sprint 5, las entregas ya eran constantes. En el Sprint 10, las prácticas de ingeniería, la colaboración y la claridad arquitectónica habían mejorado notablemente.

Lección: Reserva tiempo para la excelencia técnica y la colaboración, incluso cuando la presión de entrega sea alta.

La crisis financiera de 2008 obligó a recortar presupuestos, y la demanda irregular de las dos áreas de negocio provocaba altibajos en las entregas. Un taller con desarrolladores y responsables de negocio reveló un problema más profundo: el equipo seguía dividido por departamentos en lugar de centrarse en el producto como un todo.

La solución:

• Un único Product Backlog para Tracked Mail.
  
  
• Dos objetivos guía: maximizar el valor y mejorar la excelencia técnica.
  
  
• Cuatro equipos más pequeños y multifuncionales para compartir conocimientos y estándares.
  
  
• Un Sprint sincronizado con planificación, revisiones y retrospectivas conjuntas.
  
  

Lección: Organizarse en torno al producto y no a silos de negocio permite priorizar mejor y reducir desperdicio.

Con la recuperación económica y la aparición de nuevos competidores, el negocio quiso acelerar. Algunos proponían sacrificar calidad para entregar más rápido —el mismo atajo que había causado problemas en el pasado—.

Esta vez, el equipo se mantuvo firme. Utilizó su historial de resultados para defender una mejor priorización en lugar de recortar esquinas. El cambio estructural clave fue designar a un único Product Owner con autoridad final sobre prioridades y retorno de inversión.

Lección: Un alto rendimiento da a los equipos la credibilidad para defender la calidad. Un Product Owner empoderado ayuda a resolver conflictos entre demandas de negocio.

Aunque el resto de la organización seguía trabajando con traspasos tradicionales entre negocio y TI, Tracked Mail había desarrollado su propia burbuja de cultura ágil: colaboración diaria, objetivos compartidos y una Definición de Hecho común. Su reputación mejoró tanto que otros equipos querían colaborar con ellos.

Lección: Los equipos pueden modelar una cultura ágil e influir en la organización sin esperar a una transformación corporativa completa.

1. Espera turbulencias iniciales: los primeros Sprints destapan problemas ocultos.
   
   
2. Involucra directamente al negocio en las retrospectivas para generar empatía.
   
   
3. Invierte en prácticas de ingeniería para asegurar una entrega sostenible.
   
   
4. Organízate en torno a productos, no a departamentos.
   
   
5. Defiende la calidad bajo presión de mercado o presupuesto.
   
   
6. Modela la cultura ágil: las historias de éxito inspiran cambios en otros equipos.
   
   

La transformación de Tracked Mail no consistió en aplicar los rituales de Scrum de forma mecánica. Se trató de usar Scrum como marco para sacar a la luz problemas, fomentar la colaboración y crear un sentido compartido de propósito.

El viaje de dos equipos desconectados a un único equipo de producto de alto rendimiento requirió resiliencia, conversaciones difíciles y la determinación de no repetir errores del pasado.

Al final, Scrum no fue la solución mágica: fue el espejo que mostró dónde debía cambiar la empresa, y el vehículo que les ayudó a llegar allí.