Mi experiencia como Delivery Manager…
Entender los errores del equipo y todas sus consecuencias, fue mi mayor aprendizaje en esta experiencia. Tenía que existir una manera de hacerlo mejor.. Esta inconformidad me llevó a conocer las metodologías ágiles, de la mano de un amigo que es Agile Coach y me guió en todo el proceso.
Estaba haciendo un trabajo empírico acompañando al equipo y cumpliendo la función de varios roles (típico en las startups). Lo primero que hicimos fue una reunión para hablar sobre la realidad, la causa de los problemas y la solución.
En esta reunión introducimos Scrum sus valores y bases empíricas e hicimos una dinámica de comparativa entre nuestra manera de trabajar y lo que nos ofrecía Scrum.
Que el equipo pudiera visualizar los beneficios era importante para que adoptaran el cambio sin tanta resistencia, con apertura y compromiso.
Ciclo de Scrum
Implementé el framework Scrum en el equipo de desarrollo y marketing de producto aplicando sus principios, valores y prácticas.
Decidimos que para adaptarnos era ideal realizar sprints de dos semanas, de esta manera podíamos inspeccionar y adaptar más rápido, no solo el logro del sprint goal sino la propia adopción del framework.

Definición de roles, artefactos y ceremonias
Nos tomó unos dos sprints adaptar el marco de trabajo al 100%, entender los roles y definir todos los aspectos que SCRUM implica. En el tercer sprint ya era más natural para el equipo asistir y celebrar las ceremonias.
El aspecto que tuvo mayor dificultad en adoptar fue la gestión del product backlog, acompañé al Product Owner en la creación del Product Backlog, decidimos apoyarnos en la herramienta Trello que el equipo ya conocía y sabía utilizar y así no introducir más cambios con nuevas herramientas.
Como todos nos estabamos adaptando, apoyé al Product Owner en la actualización y orden de los ítems y requerimientos plasmados en el Product Backlog estableciendo plan de release relacionado a las necesidades que agregaban valor al desarrollo del producto.
Decidimos hacer sprints de dos semanas, para inspeccionar y adaptar más rápido. Facilité las ceremonias Scrum (Sprint Planning, Daily Meeting, Sprint Review, Sprint Retrospective). Los developers en el tercer sprint ya dominaban las Daily casi sin necesidad de que interviniera.
Promoví conversaciones sobre la agilidad del negocio y cambio dentro de la organización dando soporte con técnicas y herramientas, sobre todo a la Directiva y Product Owner, logrando sesiones one to one muy productivas.
Colaboré activamente en la implementación del producto en el equipo técnico de especialistas, para garantizar su adopción adecuada y acompañarlos en el cambio.
Sobre la medición y KPIs
Nuestro mayor enfoque y prioridad fue implementar scrum como marco de trabajo colaborativo para inspeccionar y adaptar rapidamente. Por ser un proyecto pequeño en objetivo y equipo, nuestra energía, la enfocamos en establcer mediciones sencillas; sistemas de medición complejos, no eran necesarios.
Nuestra principal métrica se convirtió en la satisfacción del cliente, la cual medimos y entendimos en los sprints review y con las métricas de usabilidad de la plataforma. Medir la satisfacción del cliente nos permitió identificar errores que corregimos, identificar nuevas funcionalidades de valor que incluímos en los siguientes realeases.
Las mediciones sobre el desempeño del equipo las establecí en base a dos aspectos esenciales:
· Nivel de compromiso: lo medía según los puntos de historia planificados y entregados en el sprint
· Calidad del producto: Según los números de incidencias por sprint
Estos KPIs básicos nos ayudaron a saber la velocidad del equipo, ayudaban a los developers a saber cuántos puntos de historia debían tomar en cada sprint, y la calidad del producto entregado a través del número de incidencias que surgían de las entregas incrementales del producto. Con cada sprint nos acercabamos más a la satisfacción del cliente, lo que motibaba al equipo y lo hacía sentirse más seguro y confiado.
De las dependencias e impedimentos
Para lograr nuesto Product Goal, las mayores dependencias e impedimentos venían del cliente, muchas veces no colaboraba en tener los requerimientos de negocio cuando le correspondía, situación que en muchas ocasiones puso en riesgo la entrega de incremento a tiempo. El cliente asumía su responsabilidad generalmente en los sprints review.
Para solucionar esto, como Delivery Manager me dediqué a que la directiva y el product owner entendieran sus roles e implicación en el proyecto, así como la importancia de adquirir el compromiso necesario para el logro de cada sprint, realicé sesiones one to one promoviendo el mindset agil y los valores de comunicación y transparencia.
El equipo de developers fue madurando con el pasar de los sprints, la transparencia en las herramientas colaborativas de trabajo ayudó al equipo a disminuir las interdependencias y los impedimentos eran resueltos en el sprint review.
Sobre las retrospectivas
Considero que las restrospectivas fueron los eventos que más nos ayudaron a madurar como equipo y a cohesionarlos con el product owner. Nuestro product owner fue el miembro del equipo que más le costó adoptar las prácticas, puesto que era una persona con muchos otros compromisos y roles dentro de la empresa, sin embargo la transparencia y las conversaciones incómodas, pero poderosas, ayudaron a mejorar el clima de trabajo en cada sprint.
Mi rol como Delivery Manager en este proyecto fue de mucho mediar entre todos los mienbros del equipo, tener el valor de generar tomas de conciencia con preguntas poderosas, aprender a establecer límites y enseñar a que cada miembro del equipo estableciera los suyos y repetara la de los demás.
Fue un gran reto profesional para mi, lograr que un equipo sin metodología se transformara en un equipo de valor no solo para el cliente sino para la propia consultora, que a partir de esta experiencia tuvo la capacidad de crear mayor valor para sus propios clientes.