Sprints, scrum, retrospectivas, backlog… Si has oído estos términos, tal vez pienses que solo son cosa de empresas de software, pero también pueden ser de utilidad para los despachos técnicos.

Scrum nació en el mundo del desarrollo tecnológico, pero la lógica que hay detrás (ciclos cortos, revisión continua y equipos autónomos) describe cómo debería funcionar un despacho de arquitectura o ingeniería que quiera tener sus proyectos bajo control.

En este artículo no proponemos que adoptes Scrum tal como es. Explicamos por qué algunos de sus principios encajan muy bien con la realidad del sector AEC y cómo puedes adaptarlos e incorporarlos en la forma de trabajar de tu despacho.

¿De dónde viene Agile y Scrum?

A finales de los años noventa, los equipos de desarrollo de software estaban atrapados en una paradoja: cuanto más planificaban al detalle, menos se parecía el resultado final a lo que el cliente realmente necesitaba. Los proyectos se alargaban, los presupuestos se inflaban y el producto quedaba obsoleto antes de salir.

La respuesta fue el Manifiesto Agile (2001): un conjunto de principios que ponen por delante la capacidad de adaptarse al cambio por encima de seguir un plan cerrado.

Scrum fue la implementación más popular de estas metodologías: trabaja en ciclos cortos llamados sprints (de una a cuatro semanas), revisa el resultado con el cliente al final de cada ciclo y ajusta el rumbo si es necesario.

Por qué el Scrum puro no funciona en un despacho técnico

Ser honestos sobre las limitaciones de una metodología es clave para identificar lo que sí nos encaja. Hay razones evidentes que no permiten aplicar Scrum directamente a un estudio de arquitectura o ingeniería:

• Las fases del proyecto no son intercambiables. No puedes entregar la estructura sin haber cerrado el proyecto básico. Las dependencias técnicas y legales marcan un orden que no es negociable.
   
• El cliente no es un product owner disponible. En Scrum, el cliente participa activamente en cada sprint. En arquitectura e ingeniería, la propiedad a menudo no puede o no quiere estar presente semanalmente en el proceso.
   
• Las entregas parciales no siempre aportan valor. Un sprint de software puede entregar una funcionalidad que el usuario ya puede utilizar. Un sprint de arquitectura puede no tener ninguna entrega visible para el cliente durante semanas.
   
• Los equipos no suelen ser multidisciplinares y estables. En un despacho, las personas trabajan en diversos proyectos a la vez y la composición del equipo varía por fases.

Los principios que sí encajan: la hibridación Scrumban

El Scrumban es una metodología híbrida que combina elementos de Scrum y de Kanban.

De Scrum toma la cadencia de revisión periódica y la cultura de mejora continua. De Kanban, la visualización del flujo de trabajo y la gestión de las tareas en curso sin imponer ciclos cerrados. El resultado es un sistema estructurado y flexible.

En un despacho de arquitectura o ingeniería, podemos aplicar la hibridación Scrumban con estas acciones:

• Reunión breve semanal de equipo (15-20 minutos) para revisar el estado de las tareas activas, identificar bloqueos y redistribuir carga si es necesario. No es una reunión de seguimiento jerárquico: es una puesta en común horizontal.
   
• Tablero visual de flujo con las tareas de cada proyecto organizadas por estado: pendiente, en curso, en revisión, entregada. Permite ver de un vistazo dónde se acumula el trabajo y dónde hay margen.
   
• Revisión por fases, no por sprints. En lugar de ciclos de tiempo fijo, se hacen revisiones internas al final de cada fase del proyecto (anteproyecto, proyecto básico, proyecto ejecutivo) para evaluar desviaciones y ajustar la planificación de la fase siguiente.
   
• Retrospectiva ligera al cierre de cada encargo, con tres preguntas simples: qué ha ido bien, qué ha ido mal y una cosa concreta que cambiaríamos la próxima vez.

Cuando estos elementos se aplican de manera consistente, el resultado va más allá de la eficiencia: los técnicos ganan autonomía sobre su trabajo y el equipo trabaja de manera más cohesionada y motivada.

No hace falta implementarlo todo de golpe. Muchos despachos empiezan por el tablero visual y la reunión semanal, y con eso ya ganan visibilidad sobre los proyectos.

¿Cómo saber si Scrumban está funcionando? 4 indicadores

Adoptar una metodología sin medir su impacto es hacer un acto de fe. Estos son los indicadores que permiten saber si la hibridación Scrumban está aportando valor real a tu despacho:

1. Reducción de tareas bloqueadas. Si el tablero visual muestra menos tareas atascadas semana tras semana, la metodología funciona.
    
2. Menos desviaciones de plazo por fase. Compara la fecha prevista y la fecha real de entrega de cada fase. Si la franja se reduce, se está mejorando la planificación.
    
3. Horas no facturadas por rehacer trabajo. Rehacer trabajo (rework) es síntoma de haber hecho una revisión demasiado tarde. Si disminuyen, las revisiones por fase funcionan.
    
4. Percepción del equipo. Una pregunta directa cada tres meses: “¿Tienes claras en todo momento cuáles son tus prioridades?” Si la respuesta es positiva, la metodología funciona.

Ninguno de estos indicadores necesita herramientas complejas para medirse, pero sí es imprescindible tener los datos disponibles y actualizados en tiempo real.

Pon los principios Agile en práctica con Coneix

El ERP de Coneix te permite hacer seguimiento del rendimiento de cada etapa de los proyectos: horas imputadas por fase, desviaciones respecto a la planificación y distribución de la carga por persona, entre otros.

Con esta visibilidad de los datos clave de tu negocio, las revisiones semanales de equipo pasan de ser una conversación sobre percepciones a ser una decisión basada en datos.

En Coneix hace años que planificamos con las metodologías Agile Scrum + Kanban. Si quieres ver cómo lo aplicamos y cómo te ayuda el ERP a tener los datos de tu equipo siempre actualizados, te lo mostramos en una demo sin compromiso: