Caso práctico Agile Education

Estudio de caso   

Resumen: El éxito de las startups remotas: de la extinción de incendios a los resultados

Arundhati Dutta se emparejó con una startup remota de reciente creación para embarcarse en un viaje de adopción de metodologías ágiles. La esperanza era que la startup mejorara el desarrollo de sus productos y su eficacia operativa. En total, el equipo estaba formado por cinco desarrolladores full-stack, un Scrum Master que también se ocupaba de la atención al cliente, un diseñador UX a tiempo parcial y dos fundadores (CEO y COO) que contribuían al desarrollo del producto y a los esfuerzos de ventas y marketing. A pesar de su compromiso con Agile y Scrum, se enfrentaron a múltiples retos, que les llevaron a la falta de productividad y al agotamiento.

Desafíos

Al principio, los retos a los que se enfrentaba esta startup giraban en torno a la estructura del equipo, los procesos de trabajo y la dinámica de comunicación. Estos retos provocaron falta de eficacia, agotamiento y ausencia de una estrategia clara de desarrollo del producto.

Falta de Product Ownersipo y Priorización

Para empezar, la ausencia de un Product Owner fue uno de los retos más importantes a los que se enfrentó esta startup remota. Al principio, el director general funcionaba como un Product Owner informal, enviando rutinariamente peticiones de funciones por correo electrónico al equipo sin una priorización estructurada. En general, esto conducía a una falta de concentración y a flujos de trabajo reactivos. Sin una persona dedicada a priorizar y gestionar las retraso, el equipo tiró del trabajo basándose en la disponibilidad inmediata y no en una hoja de ruta estratégica.

Entorno de trabajo reactivo

Sin una lista de prioridades, el equipo respondía con frecuencia a peticiones ad hoc del director general. Éstas incluían cambios repentinos en el diseño o peticiones para completar una función en un plazo ajustado, sólo para que esa función fuera abandonada antes de su despliegue. Sin duda, este modo de lucha constante contra los incendios hizo que los desarrolladores se sintieran desmoralizados y fatigados. A menudo, no había sensación de progreso o logro constantes, ya que muchas de las funciones en las que trabajaba el equipo se consideraban más tarde innecesarias o incompletas.

Proceso Sprint no estructurado

Anteriormente, el equipo operaba en periodos de tres semanas. Sprintspero no había una estructura clara ni se respetaban los objetivos del Sprint. Como era de esperar, al final de estos Sprints, a menudo carecían de un incremento de producto demostrable. El director general y el director de operaciones rara vez asistían Opiniones sobre Sprint. En consecuencia, en lugar de servir a su propósito previsto, las Revisiones Sprint se convirtieron en inventarios de tareas en lugar de reflejar el valor entregado a los clientes. Como resultado, no se rendía cuentas de la entrega de incrementos de producto acabados y enviables.

Retraso en la toma de decisiones y circuitos de retroalimentación 

Además, la falta de participación de la dirección en las Revisiones de Sprint retrasaba sistemáticamente los comentarios críticos. Incluso cuando el equipo completaba una función, no estaba seguro de si estaba lista para su lanzamiento porque el director general a veces enviaba cambios adicionales después del Sprint. Innegablemente, esta incertidumbre provocaba ciclos de desarrollo más largos y una falta de confianza en los lanzamientos de productos.

Lagunas de comunicación y falta de cohesión del equipo

Este equipo remoto de una startup funcionaba de forma totalmente virtual, basándose principalmente en la comunicación transaccional a través de Google Hangouts. Aunque discutían regularmente las tareas y el progreso, había poca conexión personal o trabajo en equipo, y estaban notando los efectos. Además, la falta de Scrums diarios agravaba el problema de comunicación. En Scrum Master mencionó a Arundhati que el equipo no veía el valor de realizar Scrums Diarios; sentían que ya sabían en qué estaba trabajando cada uno. Sin duda, esta ausencia de comprobaciones periódicas provocó una desalineación y un mayor aislamiento de las prácticas de trabajo.

Retrospectivas de sprints y mejora continua

Además, el equipo descuidaba o realizaba a medias las Retrospectivas de Sprint. Hasta ahora, no consideraban valiosas las retrospectivas, lo que conducía a una mejora continua mínima. En ocasiones, realizaban retrospectivas, pero consideraban que el esfuerzo no producía resultados tangibles. Por ello, sin una reflexión periódica sobre su proceso, el equipo seguía repitiendo los mismos errores, lo que les desmotivaba aún más con el paso del tiempo.

Cuellos de botella en el diseño

El diseñador de UX trabajaba a tiempo parcial, lo que provocaba frecuentes retrasos en la entrega de los diseños de experiencia de usuario. Como resultado, los desarrolladores a menudo tenían que esperar a recibir las aportaciones del diseño antes de proceder al desarrollo. Sin duda, este cuello de botella ralentizaba el progreso del producto y alargaba el ciclo general del Sprint.

Estimación y planificación ineficaces

El equipo utilizó estimaciones aproximadas basadas en horas en lugar de puntos de historialo que a menudo provocaba imprecisiones en su planificación. El director general esperaba que estas estimaciones fueran precisas, pero la realidad del desarrollo ágil es que las estimaciones suelen ser variables. La incapacidad de cumplir estas expectativas provocó frustración y tensión entre la dirección y el equipo de desarrollo. Los desarrolladores también se sentían incapaces de comunicar la incertidumbre inherente a la estimación.

Estiramiento de liderazgo

Sin duda, el Director General tenía una capacidad cada vez más limitada. Además de actuar como Product Owner informal, se ocupaba de todo, desde la recaudación de fondos hasta las asociaciones de ventas, además de gestionar a los desarrolladores. Su falta de tiempo para centrarse en el desarrollo del producto contribuía a las solicitudes de trabajo ad hoc, la ausencia en las ceremonias Scrum clave y la falta de una visión del producto a largo plazo. El Director de Operaciones, aunque participaba en marketing y ventas, tenía una interacción mínima con el equipo de desarrollo. Esto creó una desconexión entre el desarrollo del producto y el posicionamiento en el mercado.

Agotamiento y fatiga del equipo

En general, la falta de estructura y de procesos claros contribuyó a un alto grado de agotamiento. El equipo se sentía constantemente presionado para cumplir plazos ajustados, muchos de los cuales eran arbitrarios y estaban sujetos a cambios. Además, como el equipo tenía que desechar funciones tras el desarrollo, sentían que su duro trabajo no era reconocido, lo que mermaba su motivación. No tenían una sensación de logro al final de los Sprints debido a la ausencia de un producto despachable.

El enfoque

Tras comprender estos grandes retos, Arundhati propuso varias soluciones que el equipo adoptó para transformar su proceso Ágil:

• Iniciativas de creación de equipos: Al principio, los desarrolladores trabajaban aislados y sólo se comunicaban transaccionalmente a través de Google Hangouts. Para fomentar el espíritu de equipo, se les animó a crear un nombre de equipo y a incorporar charlas semanales de café para entablar relaciones.
• Reuniones diarias de Scrum: Arundhati destacó el valor del Scrum Diario. El equipo adoptó herramientas para gestionar Scrums Diarios remotos, mejorando la comunicación y la coordinación.
• Nombrar un Product Owner y priorizar los atrasos: La startup contrató a un Product Owner dedicado a priorizar el backlog de productos. Establecieron objetivos a largo plazo y redujeron la necesidad de que el director general asignara trabajo ad hoc. El equipo pasó de reaccionar a peticiones ad hoc a trabajar a partir de un backlog debidamente priorizado. Esto garantizó que en cada Sprint sólo se abordaran las tareas más importantes.
• Incremento de producto demostrable: El equipo estableció un Definición de Hecho (DoD)Garantizando que cada Sprint terminara con un incremento de producto funcional y demostrable.
• Presentamos el Tiempo de Amortiguación: Para evitar el agotamiento, Arundhati ayudó al equipo a incorporar un tiempo de amortiguación de 30% en sus Sprints para aumentar la velocidad y la sostenibilidad.
• Hacer que las retrospectivas sean atractivas: El equipo celebró Retrospectivas de Sprint creativas para fomentar la mejora continua. Esto hizo que el proceso fuera más atractivo y productivo.
• Sprints de dos semanas: Redujeron la duración del Sprint de tres semanas a dos. Esto permitió iteraciones más rápidas, una retroalimentación más rápida y una mejor adaptabilidad a los cambios. También conservaron la flexibilidad para volver a los Sprints de tres semanas si era necesario.
• Adoptar puntos de historia para la estimación: El equipo aprendió a estimar en puntos de historia en lugar de horas, lo que ayudó a establecer expectativas más realistas en torno a la finalización de las tareas y dio una mejor sensación de progreso.
• Diseñador UX a tiempo completo: Al darse cuenta de los retrasos causados por tener un diseñador a tiempo parcial, la startup contrató a un diseñador a tiempo completo para agilizar el proceso de diseño y permitir un desarrollo más rápido.
• Invertir en formación: Arundhati impartió formación adicional sobre Scrum al Scrum Master, al Equipo de Desarrollo y al Product Owner. Esto profundizó su comprensión de los principios ágiles, garantizando el éxito a largo plazo.
• Seguimiento de la felicidad del equipo: Por último, Arundhati introdujo el uso de una métrica de la felicidad. Esto permitió al equipo hacer un seguimiento y mejorar su estado de ánimo y motivación a lo largo del tiempo.

Efectos y resultados clave

Seis meses después de aplicar estos cambios, el equipo experimentó mejoras notables:

• Apropiación y capacitación del equipo: Developers se sintieron más dueños de su trabajo y de su producto.
• Incrementos enviables: El equipo desarrolló un ritmo constante de entrega de un incremento de producto despachable al final de cada Sprint. Aunque a veces se quedaban cortos, utilizaban las Retrospectivas de Sprint para mejorar continuamente.
• Reducción de los cuellos de botella: Un diseñador a tiempo completo agilizó el proceso de desarrollo, lo que provocó menos retrasos.
• Mejora del enfoque de liderazgo: El director general pudo centrarse más en la recaudación de fondos y el crecimiento estratégico, mientras el Product Owner se encargaba de la gestión diaria del producto. Como resultado, la empresa estaba en conversaciones para conseguir una ronda de financiación inicial.
• Moral de equipo: Con retrospectivas regulares y una mejor comunicación, mejoró la moral del equipo y se redujo el agotamiento.
• Mayor transparencia: El director general y el director de operaciones aumentaron la transparencia compartiendo los esfuerzos de marketing y ventas con todo el equipo, fomentando un sentido de propósito compartido.

Conclusión

Esta transformación en una startup remota en tan sólo seis meses es un testimonio de la importancia de una implementación Agile adecuada, en la que los roles estructurados, la comunicación clara y la priorización estratégica impulsan el éxito. Al abordar retos profundamente arraigados y fomentar una cultura de mejora continua, la startup pudo mejorar la cohesión del equipo, ofrecer valiosos incrementos de producto y mejorar el enfoque de liderazgo, sentando las bases para un crecimiento sostenible.

Sobre Arundhati Dutta

Arundhati Dutta es una experimentada fundadora de startups y propietaria de productos con más de 10 años de experiencia en la creación de productos en empresas desde cero utilizando metodologías Agile, Scrum y Lean. Tiene un máster en Trabajo Social Clínico por la Universidad de Nueva York (NYU) y ha prestado activamente servicios de coaching y asesoramiento a particulares y startups. Arundhati aporta a sus talleres una mezcla única de sus conocimientos y habilidades en producto, psicología, Lean, agilidad y gestión del cambio. También aporta diversas perspectivas internacionales por haber vivido y trabajado en más de 8 ciudades de EE.UU. y la India. Arundhati reside actualmente en San Francisco y es coorganizadora de la sección Women in Agile San Francisco.

Más estudios de caso del Scrum@Scale