7 min lectura • Guide 829 of 877
Tiempo de Innovación en Equipos Ágiles
La innovación necesita tiempo. GitScrum ayuda a los equipos a asignar y trackear tiempo de innovación, asegurando que el trabajo creativo ocurra junto a los compromisos de entrega.
Por Qué Tiempo de Innovación
El Caso para la Inversión
VALOR DEL TIEMPO DE INNOVACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SIN TIEMPO DE INNOVACIÓN: │
│ ──────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sprint 1: Features ││
│ │ Sprint 2: Features ││
│ │ Sprint 3: Features ││
│ │ Sprint 4: Features ││
│ │ ... ││
│ │ ││
│ │ RESULTADOS: ││
│ │ • El equipo se quema ││
│ │ • Deuda técnica acumula ││
│ │ • Skills se estancan ││
│ │ • Sin mejoras breakthrough ││
│ │ • Innovación ocurre en otro lugar (o en ninguno) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CON TIEMPO DE INNOVACIÓN: │
│ ───────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sprint 1: Features (80%) + Innovación (20%) ││
│ │ Sprint 2: Features (80%) + Innovación (20%) ││
│ │ Sprint 3: Features (80%) + Innovación (20%) ││
│ │ Sprint 4: Features (80%) + Innovación (20%) ││
│ │ ││
│ │ RESULTADOS: ││
│ │ • Equipo se mantiene energizado ││
│ │ • Mejoras técnicas ocurren ││
│ │ • Nuevas habilidades desarrolladas ││
│ │ • Herramientas internas creadas ││
│ │ • Ideas breakthrough emergen ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EJEMPLOS FAMOSOS: │
│ • 20% time de Google → Gmail, AdSense │
│ • 15% time de 3M → Post-it Notes │
│ • ShipIt days de Atlassian → Features clave │
│ │
│ INNOVACIÓN ES UNA INVERSIÓN, NO UN COSTO │
└─────────────────────────────────────────────────────────────┘
Modelos de Implementación
Diferentes Approaches
MODELOS DE TIEMPO DE INNOVACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODELO 1: DÍA SEMANAL │
│ ─────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ VIERNES = DÍA DE INNOVACIÓN ││
│ │ ││
│ │ Lun-Jue: Trabajo de sprint ││
│ │ Viernes: Tiempo de innovación (20%) ││
│ │ ││
│ │ ✅ Ritmo regular ││
│ │ ✅ Fácil de proteger ││
│ │ ⚠️ Viernes frecuentemente se sacrifica ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 2: ASIGNACIÓN POR SPRINT │
│ ────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CADA SPRINT: 15-20% CAPACIDAD ││
│ │ ││
│ │ Sprint planning: Reservar 20% para innovación ││
│ │ Equipo elige cuándo durante el sprint ││
│ │ ││
│ │ ✅ Flexible ││
│ │ ✅ Incorporado en capacidad ││
│ │ ⚠️ Puede ser exprimido por trabajo "urgente" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 3: SPRINT DE INNOVACIÓN │
│ ────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SPRINT DE INNOVACIÓN TRIMESTRAL ││
│ │ ││
│ │ S1 S2 S3 S4 S5 [Sprint Innovación] S1 S2 S3... ││
│ │ ││
│ │ Un sprint completo por trimestre ││
│ │ Enfoque enteramente en innovación ││
│ │ ││
│ │ ✅ Enfoque profundo ││
│ │ ✅ Proyectos sustanciales posibles ││
│ │ ⚠️ Gaps largos entre innovación ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 4: HACKATHONS │
│ ─────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ HACKATHONS DE 24-48 HORAS (Trimestral) ││
│ │ ││
│ │ Innovación intensiva, time-boxed ││
│ │ Proyectos de equipo o cross-team ││
│ │ Demo y evaluación al final ││
│ │ ││
│ │ ✅ Emocionante, alta energía ││
│ │ ✅ Colaboración cross-team ││
│ │ ⚠️ Profundidad limitada ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
En Qué Trabajar
Categorías de Innovación
ACTIVIDADES DE TIEMPO DE INNOVACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CATEGORÍA: EXPLORACIÓN TÉCNICA │
│ ─────────────────────────────── │
│ • Aprender nuevo framework/lenguaje │
│ • Experimentar con nuevas herramientas │
│ • Proof of concept para features futuras │
│ • Evaluar approaches alternativos │
│ │
│ CATEGORÍA: HERRAMIENTAS INTERNAS │
│ ──────────────────────── │
│ • Herramientas de productividad para desarrolladores │
│ • Scripts de automatización │
│ • Herramientas de debugging │
│ • Dashboards internos │
│ │
│ CATEGORÍA: MEJORA TÉCNICA │
│ ─────────────────────────────── │
│ • Refactoring │
│ • Optimización de performance │
│ • Reducción de deuda técnica │
│ • Cobertura de tests │
│ │
│ CATEGORÍA: MEJORA DE PROCESO │
│ ───────────────────────────── │
│ • Mejor CI/CD │
│ • Monitoreo mejorado │
│ • Documentación │
│ • Onboarding de desarrolladores │
│ │
│ CATEGORÍA: EXPERIMENTOS DE PRODUCTO │
│ ───────────────────────────── │
│ • Prototipos de features │
│ • Experimentos de UX │
│ • Exploraciones de pain points de clientes │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REGLAS BASE: │
│ ───────────── │
│ ✅ Debe relacionarse al equipo/producto de alguna manera │
│ ✅ Puede ser individual o en grupo │
│ ✅ No necesita estar en backlog │
│ ✅ Compartir resultados (demo, doc, talk) │
│ ❌ No trabajo regular disfrazado │
│ ❌ No distracciones personales │
│ │
└─────────────────────────────────────────────────────────────┘
Protegiendo el Tiempo
CÓMO PROTEGER TIEMPO DE INNOVACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. SOPORTE DE LIDERAZGO │
│ • Liderazgo debe comprometerse públicamente │
│ • No cancelar por "urgencias" │
│ • Celebrar outcomes de innovación │
│ │
│ 2. INTEGRAR EN CAPACIDAD │
│ • Contar solo 80% de capacidad para features │
│ • 20% reservado = no negociable │
│ • Planning respeta esta separación │
│ │
│ 3. TRACKEAR COMO MÉTRICA │
│ • % de tiempo realmente usado para innovación │
│ • Reportar en retrospectivas │
│ • Accountability visible │
│ │
│ 4. HACER OUTCOMES VISIBLES │
│ • Demo days para proyectos de innovación │
│ • Celebrar herramientas adoptadas │
│ • Documentar mejoras logradas │
│ │
│ 5. CALENDAR BLOCKING │
│ • Bloques de calendario para innovación │
│ • Tratarlos como reuniones importantes │
│ • No programar encima │
│ │
│ RECORDATORIO: │
│ Si tiempo de innovación "siempre puede esperar", │
│ nunca ocurrirá. Debe ser tan protegido como │
│ compromisos de sprint. │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Proteger explícitamente en planning
- Hacer regular no ad-hoc
- Compartir outcomes con demos y docs
- Balance individual/equipo ambos funcionan
- Conectar a valor del equipo/producto
- Medir y celebrar resultados