¿Por qué quisimos iterar el desarrollo Agile?
En Wareclouds siempre nos llama la atención estar experimentando, estudiando y probando nuevas metodologías y tecnologías que puedan subir la calidad de nuestro trabajo. En relación con el desarrollo tecnológico de nuestro producto, nos habíamos estado basando, con buenos resultados podríamos decir, en desarrollo Agile (ver Clean Agile y Clean Code).
Sin embargo, teníamos una piedra en el zapato con el rol de Product Owner por dos motivos:
- (i) Para un equipo de desarrollo de una startup no nos hacía sentido tener este rol full time,
- (ii) Queríamos democratizar que cualquier miembro del equipo tuviera una forma fácil de poder levantar mejoras que vinieran desde cualquier área, sin necesariamente saber mucho sobre tecnología.
¿Pero cómo podíamos hacerlo evitando esas incómodas “pedidas de pasillo” que el Product Owner lograba ordenar?
Enter Shape Up...
AGILE & SHAPE UP (CON COMENTARIOS DE CHAT-GPT)
Descubrimos Shape-Up, que es una metodología de desarrollo de software que se estaba popularizando en el ecosistema de startups locales.
Así que, ya entrando en materia, que nos cuente mejor Chat-GPT sobre las virtudes de Agile y Shape Up.
- 🎙️ ¿Cuáles son las diferencias entre desarrollo Agile y la metodología Shape Up?
🤖 Desarrollo Agile es un set de principios y prácticas que permite a equipos entregar software de alta calidad rápida e iterativamente, enfatizando en la colaboración, flexibilidad y respuesta al cambio.
La metodología Shape Up se enfoca en ciclos de 6 semanas de discovery, shaping y execution. Así, los equipos primero identifican los resultados que quieren alcanzar, para moldear el trabajo que permita llegar a esos outcomes y finalmente ejecutar ese plan.
Una principal diferencia, es el foco de Shape Up en defining and shaping antes de comenzar la ejecución, mientras que Agile se enfoca en trabajar el software de manera rápida e iterativa.
También aprovechamos de preguntarle qué opinaba sobre los Product Owners.
- 🎙️ ¿Qué piensas sobre los Product Owners en desarrollo Agile?
🤖 Los Product Owners juegan un rol vital en desarrollo Agile, ayudando a asegurar que el equipo de desarrollo trabaje en los features más importantes y que el producto cumpla las necesidades de los stakeholders.
Así que nos propusimos probar cambiar este rol vital para que sea cumplido de forma democrática por todos los miembros de la compañía, y quién decida lo más importante no esté centralizado en solo un rol.
METODOLOGÍA DE DESARROLLO EN WARECLOUDS
Nuestra metodología resultante tiene adaptaciones de Shape Up, Agile y Lean, que sentimos se adaptaban bien a los objetivos de desarrollo que queríamos llegar, y aquí les contamos en más detalle cuáles son las etapas:
- Shape:
- Bet:
- Planning:
- Design:
- Develop:
Miembros de distintas áreas elaboran un pitch, en donde hay especial foco en justificar el problema (ojalá con datos), y solo un bosquejo de la solución sin dar detalles de cómo hacerla (aquí la idea es que los equipos que resuelvan el problema entrarán al detalle con mínimo sesgo).
Líderes de distintas áreas evalúan los pitches, dan feedback, y determinan cuáles son los problemas más importantes por resolver usando un framework de evaluación de problemas de Lean Product Development.
El equipo de desarrollo realiza una estimación del trabajo de los pitches a través de un planning poker. Con esto, se define qué pitches, ordenados primero por relevancia y luego por dificultad técnica, logran ingresar en un ciclo de desarrollo de 4 semanas.
El equipo de desarrollo detalla la solución a implementar de los pitches. Esta etapa puede realizarse en conjunto con miembros de otros equipos.
Se realiza el desarrollo del software usando prácticas de metodología Agile.
Las etapas previas al desarrollo toman entre 1 a 2 semanas, y luego de completar el desarrollo hay un periodo de cool down similar a lo propuesto en Shape Up para realizar ajustes, estudiar, o tener feedback. La idea es que el ciclo completo tome 6 semanas.
¿Cómo nos fue?
En el primer ciclo de desarrollo solo se levantó 1 pitch, así que se podría decir que partimos con el pie izquierdo. Realizamos capacitaciones al equipo, ejemplos y templates para desarrollar pitches y dimos seguimiento a los problemas que se levantaban que tenían que ver con tecnología para incentivar a que los propusieran como pitches. En el segundo ciclo se levantaron 12 pitches, así que logramos pasar la inercia inicial de cómo hacíamos las cosas, y hasta la fecha el ritmo de propuestas de desarrollo se ha mantenido alto.
Así, a la fecha hemos podido cumplir nuestro objetivo, manteniendo lo mejor de ambos mundos, una metodología de desarrollo ampliamente popular que nos ha entregado muy buenos resultados, y la posibilidad de permitir que todos tengan voz en levantar problemas para que se resuelvan con tecnología.
Mejoras futuras
Como punto para mejorar, notamos una brecha en qué es lo que viene después que se lanza un feature a producción. No había responsable de monitorear, incentivar la adopción y revisar con lujo de detalle que la funcionalidad desarrollada haya cumplido con las expectativas de nuestros usuarios. Así por supuesto, caímos algunas veces en features que su adopción no fue la esperada (igual que nos pasó al principio con este mismo cambio de metodología!). Ya estamos trabajando en adoptar prácticas de Dev Ops, que es justamente el área de desarrollo que define la metodología de cómo asegurarse que nuestro producto mejore y entregue valor continuamente una vez puesto en producción. También, como la etapa de Design viene posterior a Planning, tenemos que mantener pitches con un scope acotado para que logre entrar en un ciclo de desarrollo, de igual manera como se realizaría bajo metodología Ágil.
Referencias
Martin, R. C. (2020). Clean agile: Back to basics. Pearson.
Martin, R. C. (2009). Clean code: A Handbook of Agile Software Craftsmanship. Prentice Hall.
Shape up V 1.8, 2019 edition. Shape Up: Stop Running in Circles and Ship Work that Matters. (n.d.). Retrieved December 16, 2022, from https://basecamp.com/shapeup,
Olsen, D. (2015). The lean product playbook: How to innovate with minimum viable products and rapid customer feedback.