En estos seis años que llevo en Zinklar, hemos pasado del manual de Scrum al pie de la letra a crear nuestra propia metodología basada en la confianza.

Me gustaría remarcar que el contexto lo es todo. No es lo mismo un equipo de desarrolladores menos experimentados que otro con años de experiencia detrás, no es lo mismo tener que trabajar un producto maduro, que tener que empezar algo desde cero y no es lo mismo una empresa en un contexto económico estable que una con dificultades…

Inicios con Scrum Puro

En nuestro caso, hace seis años éramos un equipo con cierta experiencia, pero en un producto que estaba naciendo. Era una época de mucha inversión, velocidad y bajo el manual del Scrum puro.

• Sprints de dos semanas.
• Ceremonias estrictas (planning, retros, demo days).
• Uso riguroso de story points en Jira.
• Sin convenciones claras sobre arquitectura ni buenas prácticas.
• Arquitectura de microservicios en expansión pero sin un motivo claro ;)

El producto y el código fue creciendo y empezamos a encontrarnos con la deuda técnica y procesos obsoletos. En ese momento tomamos la decisión de ralentizar el desarrollo del producto para poder aplicar una serie de mejoras clave para poder seguir creciendo:

• Definición de estrategia técnica a corto, medio y largo plazo.
• Nueva arquitectura adaptada a nuestras necesidades, y unificación en nuestros repositorios.
• Saneamiento del código mediante la retirada de features en desuso.
• Formación interna para todo el equipo sobre las nuevas directrices de arquitectura y mejores prácticas de desarrollo.

En un año, pasamos del 30% del tiempo del equipo a resolución de bugs / soporte, a un porcentaje marginal. Teniendo más tiempo para dedicar al desarrollo y un producto de mucha más calidad para los clientes.

Los 6 Pilares de Nuestra Agilidad en 2026

El último gran punto de inflexión empezó en 2025 aplicando inteligencia artificial en Producto y Desarrollo, aunque de esto ya hablaré en otra ocasión.

Actualmente, somos 6 desarrolladores y nuestra metodología actual se basa en la confianza y el contexto, no en la monitorización:

1. Sin sprints ni story points

No medimos quién hace más tareas ni fiscalizamos cada minuto. Trabajamos por iniciativas que vamos priorizando e intentamos siempre que la entrega de valor sea lo antes posible para tener feedback e iterar de nuevo.

2. Desarrolladores en Producto

Algunos de los desarrolladores ahora se involucran en el discovery. Entender el problema desde el inicio evita que tengamos que cambiarlo todo cuando la definición llega a la tecnología.

3. Refinement profundo

Antes de picar código, dedicamos todo el tiempo necesario a analizar la arquitectura y hacer vertical slicing para entregar valor lo antes posible.

4. Reuniones al mínimo necesario

Hacemos reuniones ad hoc cuando se necesitan, pero intentamos mantener solo la daily meeting y 1to1s. Las retrospectivas, debates, traspasos de conocimiento, formaciones, etc., se hacen cuando se ve una necesidad, con una temática concreta y lideradas por cualquier persona del equipo.

5. Crecimiento Personal

Damos mucha importancia en tener un plan de desarrollo para todas las personas del equipo, encontrando la intersección entre lo que se quiere a nivel personal y lo que es posible dentro de la empresa. Esto hace que el equipo esté motivado y generemos un gran ambiente de trabajo.

6. IA como aliada

Escribimos el código apoyándonos en IA, lo que nos permite reducir errores y centrarnos en la revisión y el output de calidad.

Quiero recalcar que todo esto fue posible gracias a que todo el equipo de Zinklar aportó su conocimiento y creyó en ello.

El nuevo cuello de botella

Irónicamente, gracias a la limpieza de deuda y al uso de IA, el desarrollo se ha vuelto tan rápido que el nuevo cuello de botella ya no es la ejecución, sino la definición de producto. Por ahora, parte de los desarrolladores trabajan más cerca del Producto. Esto tiene sus pros y contras, aunque de esto ya hablaré en otra ocasión.

Tras seis años, hemos aprendido que el mejor equipo no es el que más tickets cierra, sino el que mejor entiende por qué está escribiendo cada línea de código.