Finalización 3ra etapa del Apprenticeship & Smart Open Space v2

Hoy estamos finalizando la 3ra etapa del apprenticeship de 10Pines, donde participé como Product Owner. Agradezco al equipo de Mentores por dejarme participar. La verdad que extrañaba muchísimo estar en el día a día de un equipo de desarrollo (¿hay algo más lindo?).

El producto que construimos es la versión 2 de Smart Open Space. Pueden acceder y usarlo desde aquí: https://smartopenspace.10pines.com/

Desde el punto de vista metodológico, para mí fue una linda experiencia porque pude probar unas cuantas cosas:

• Usamos sólo Miro para hacer el Discovery y el Delivery. No usamos ninguna herramienta de gestión ágil (Trello/Jira). Nos resultó comodísimo y muy visual. Hicimos todos los mapeos de flujos, priorizaciones, diagramas, mocks, etc en el mismo lugar. Fue nuestro espacio compartido de trabajo donde recordamos todas las conversaciones.
• Usamos example mapping para charlar y recordar cada una de las historias de usuario. Y lo hicimos en equipo: Product Owner, Scrum Master y equipo de desarrollo.
• No estimamos ninguna historia. Sin embargo, en un par de iteraciones y simplemente contando cuántas tarjetas podíamos terminar por iteración, pudimos hacer predicciones acerca de nuestro progreso y contestar esas preguntas necesarias en cualquier organización acerca de cuánto tiempo necesitábamos para terminar.

El producto sobre el que estuvimos trabajando es Smart Open Space. Construimos esta herramienta hace un par de años como un trabajo final de la Universidad Nacional de Quilmes. El problema que queríamos resolver era la gestión del Marketplace de un Open Space (encolamiento de participantes y creación de la agenda de manera colaborativa). Hicimos un pívot de esta idea inicial con la siguiente hipótesis: ¿Podemos construir una herramienta simple que sirva para organizar conferencias virtuales? Con esta hipótesis en mente, pensamos nuestra propuesta de valor usando un Elevator Pitch:

A partir de esta hipótesis, pensamos cuáles eran las funcionalidades mínimas que tendría que tener este experimento y las priorizamos:

• Debemos mejorar el aspecto del open space y permitir que los oradores especifiquen el link a la videoconferencia
• El organizador debería poder abrir la convocatoria y cerrarla cuando ya no se reciben postulaciones
• Es importante que soportemos tracks. Que existan temáticas es muy frecuente en la mayoría de las conferencias.
• Una conferencia puede durar varios días.

A partir de este priorización, hicimos un storymap donde diferenciamos las tareas que ya existen de las que teníamos que implementar:

Para hacer el storymap, pensamos un ejemplo frecuente de organización de una conferencia:

A partir del storymap, escribimos las stories usando example mapping. Pensar los ejemplos con el equipo nos permitió entender mejor el scope de cada tarjeta, etc. Al story map, le agregamos algunos wireframes que tenían el propósito de entender mejor la funcionalidad que queríamos desarrollar.

A partir de las stories, armamos un Backlog dentro de un Kanban board, dentro de Miro con links a los example mappings que habíamos escrito. Tener el board en el mismo lugar, donde hicimos el discovery, permite que el board sean solo tickets que identifiquen el estado. No existe desperdicio de tener que trasladar esta información a otros lugares. Y resulta mucho más visual, ya que estamos en la misma herramienta (no se pierde esta información).

En la 2da demo, noté que el equipo terminaba 4 tarjetas por iteración. Esto me permitió pensar que podíamos contar los tickets para establecer una medida de la capacidad del equipo y poder inferir la fecha de terminación de nuestro experimento inicial:

Así es. En la 2da semana nos dimos cuenta que necesitábamos 3 iteraciones, y un poco más, para terminar con eso que habíamos pensado como 1er experimento. Sabíamos que no íbamos a terminar con todas las funcionalidades pensadas inicialmente. Quedaría la última, la menos prioritaria para después. ¿Cómo hicimos esto? Simplemente partiendo el trabajo en tarjetas pequeñas y contando, como vi en el post de Josh que había sugerido Don Wells ¡en el año 2001!

Observaciones

• No hace falta usar una herramienta de gestión ágil tradicional (Trello/Jira), sólo usamos Miro. De hecho, considero que usar un board para hacer el discovery y el delivery conlleva menos desperdicio a la vez que provee una herramienta mucho más visual.
• Es importantísimo incluir al equipo de desarrollo en todo el proceso desde el principio. Partir del problema, explorar soluciones, planificar, pensar como hacer el slicing. Hicimos todo en equipo y resultó muy eficiente.
• No perdimos tiempo en estimar, pero tratamos de partir el trabajo en incrementos pequeños. Luego pudimos medir la capacidad del equipo con bastante precisión y sin ningún esfuerzo.El equipo hacía un pull request para el backend y otro para el frontend. Pude ver que éstos se creaban y cerraban muy rápidamente. En iteraciones de 1 semana, cerramos 8 pull requests en promedio (entiendo que esto es casi trunk-based development)