Cómo aumentamos la autonomía del equipo de desarrollo
Basado en nuestra presentación “No todas usamos Scrum”.
“Es que todos usan Scrum”. Como la mayoría de las empresas (ágiles) de desarrollo de software, en Fintual desarrollábamos con esta metodología de moda.
Scrum tiene fieros defensores de su éxito a partir de los distintos roles y las muchísimas actividades que involucra la metodología. Sin embargo, no todo es tan perfecto como sus discípulos ágiles defienden. En especial para una startup.
Problemas en Fintual
A septiembre del 2019 éramos nueve en el equipo de devs de Fintual y Agustín tenía el rol de Product Owner. En ese contexto, Scrum nos traía muchos problemas.
- Era difícil priorizar entre objetivos pequeños y bien definidos (ej. mejorar un botón) vs. algunos más grandes y de largo plazo (ej. nuevo onboarding de México).
- Los sprints se alargaban. Dos semanas pasan volando lo que hacía difícil terminar bien las tarjetas. Algo interesante es que los mejores proyectos eran los que se alargaban más de un sprint a cargo del mismo desarrollador.
- La planificación no funcionaba y era ineficiente. Se planificaba en detalle lo que se iba a hacer, pero no se definía bien inicialmente el problema y la solución. A veces, el problema terminaba siendo irrelevante o la solución no era el camino correcto.
- Se perdía el momentum ganado por el equipo de desarrollo. Se requiere tiempo para lograr esa sinergia, pero no se aprovecha al cortar en cada sprint.
Sin embargo, el problema más grande era la poca autonomía de los devs. Al separar cada feature en tareas diminutas en el sprint planning, se pierde el panorama general a cambio del foco en el detalle específico. Con esto, los desarrolladores se reducen a tomadores de tarjetas sin ser responsables de pensar en cómo se unen todas las piezas.
Hola Shape Up, adiós Scrum
En este contexto, los founders encontraron el libro Shape Up de Basecamp, una empresa de software estadounidense muy conocida. Ellos tenían problemas parecidos a los nuestros y proponían una nueva manera de desarrollar.
Todos los que estábamos en el equipo nos leímos el libro, discutimos si nos parecía bien y finalmente decidimos cambiarnos. Ahora cada persona que entra a Fintual, también lo lee en sus primeras semanas.
No más backlogs, no más cards
¿Qué es Shape Up? Es un set de herramientas que entrega distintas técnicas de desarrollo. Según el libro:
“Con Shape Up se da forma a los proyectos y después se desarrollan en ciclos de seis semanas. Los equipos tienen la responsabilidad de éstos y se reducen riesgos.”
Todo el proceso de desarrollo de un proyecto tiene tres etapas:
- Shaping: se idean los proyectos a desarrollar (features) y se modelan
- Betting: se deciden los proyectos a desarrollar en el siguiente ciclo
- Building: se desarrollan los proyectos elegidos
En todo el proceso pasamos de una idea a un producto completamente terminado.
El detalle de la metodología está muy bien explicado en el libro (recomiendo fuertemente leerlo). Sin embargo, tuvimos que adaptar Shape Up a nuestro contexto en Fintual.
De una idea a un proyecto
Todo el proceso de desarrollo nace primero con una idea, muchas veces a partir de un problema. Puede ser una nueva feature o una mejora a un proceso; cualquier cosa que involucre desarrollo.
Shaping es cuando una persona pasa esta idea a algo formado, ni muy concreto ni muy abstracto. Si es muy concreto se pierde el espacio para la creatividad. Si es muy abstracto no hay suficiente contexto para que los builders (equipo de desarrollo) tomen decisiones y hagan trade-offs.
“Shapear” tiene cuatro pasos:
- Establecer límites. El tiempo es fijo (seis semanas) y el alcance variable.
- Encontrar los elementos de la solución, sin estancarse en los detalles. Los builders se encargarán de aterrizarla y desarrollarla.
- Abordar riesgos y rabbit holes
- Escribir el pitch
¿Qué es un pitch? Es un documento (en Fintual usamos Notion) que incluye problema o motivación, apetito, solución, rabbit holes y no-goes.
El “apetito” es un concepto de Shape Up que se relaciona con “cuánto tiempo le quiero dedicar a esta solución”. Ojo, no es una estimación a partir de la solución, es “cuánto vale esta solución?” (en general son 6 o 2 semanas). Al contrario de Scrum, parto con un número de semanas y termino con un diseño en base a ese número.
En Fintual, cualquier persona del equipo puede shapear en cualquier momento. No es necesario saber desarrollar, pero la persona debe ser capaz de juzgar lo que es posible de hacer, y distinguir lo fácil de lo difícil.
La gran apuesta
El ciclo inicia con la Betting Table.
En una reunión por Google Meet, cuatro personas (que inicialmente eran los founders y ahora rota entre personas de la empresa) deciden qué pitches serán elegidos y los equipo que los desarrollarán. Estas personas tienen completo conocimiento de la disponibilidad de los devs y designers, además de las prioridades del negocio y las preferencias de los builders (tenemos 12 🌟 para repartir entre los pitches según nuestro interés).
El resto de la empresa puede conectarse, pero solo como espectadores. Con esto, la Betting Table (o Betty Table como ahora le decimos) es de los eventos más esperados del ciclo. Hay mucha tensión y emoción, en especial entre los shapers que quieren que sus pitches sean elegidos y los devs y designers que ven cómo se determina su destino para las siguientes semanas.
¿Por qué es necesario la Betting? Siempre hay más pitches que devs para desarrollarlos, con lo que la única opción es “apostar”. Es una apuesta all-in porque los equipos solo trabajarán en su pitch y no en otras tareas, para no perder el momentum que mencioné antes.
En esta reunión se arman los grupos de builders y se les asigna un pitch de seis semanas o tres pitches de dos. Es una conversación en que se busca llegar a un acuerdo entre los que componen la Betting Table. De hecho, nunca hemos necesitado recurrir a una votación.
Algo importante: no tenemos backlog.
Los pitches que no quedan elegidos se descartan. Si la idea es realmente importante, siempre va a volver a aparecer en forma de otro pitch.
A programar
La última etapa de Shape Up es el Building, en que se desarrolla el pitch. El equipo de builders en Basecamp lo componen 1 o 2 desarrolladores, 1 diseñador y 1 persona a cargo QA/testing. Como en Fintual los devs programamos, testeamos, hacemos QA, trabajamos en front y back, web y mobile; nuestros equipos para cada pitch se componen (en general) de dos developers y un designer, si el proyecto tiene componentes de frontend.
Tres principios de Shape Up que son claves para nosotros:
1. Full responsibility. Al equipo se le asigna un proyecto, no tareas. Ellos son los encargados de definir los to-dos y los scopes para construir en el plazo que tienen. Con esto, los devs tenemos mucha autonomía sobre el desarrollo.
2. Incrementos constantes. Seguimos siendo ágiles. Tenemos que mostrar avances funcionales durante el ciclo y nunca pasar todo a producción el último día.
3. Scope hammering. El tiempo es fijo por lo que tenemos que decidir cuándo parar. Es muy fácil que crezcan los scopes y cortar algunos no significa bajar la calidad de la solución.
Tenemos canales de Slack para cada equipo del pitch, junto con sus “consejeros”. Estos son los equivalentes a stakeholders del pitch; generalmente la persona que lo escribió y las más expertas en el tema o las más afectadas por el proyecto.
Sin kanban, ¿cómo mostramos el progreso?
Por un lado, tenemos el hill chart que usamos del mismo Basecamp. En éste mapeamos los scopes y lo mostramos todas las semanas en nuestras reuniones de “Parlamento”, en las que está toda la empresa.
Cuando se acaban las seis semanas de desarrollo, tenemos nuestro segundo gran evento: Fintualpalooza. Los builders presentan su trabajo del ciclo, para que todo el resto del equipo (devs y no devs) conozca las nuevas features, cambios y mejoras a la aplicación.
Code and chill
Después del intenso trabajo de las seis semanas de building, tenemos tres de cooldown. En éstas los desarrolladores y diseñadores de los proyectos son libres de trabajar en lo que quieran: mejora continua, arreglar bugs, shapear, aprender cosas técnicas o probar nuevas ideas.
Eso significa que un tercio de nuestro tiempo queda a nuestra libre disposición. Si en el building encontraste un código que te pican los dedos por refactorizar, lo puedes hacer. Si quieres ver tutoriales de React Native para conocer más de la app móvil, también. Y de las cosas más importantes: si quieres, tienes ese tiempo para shapear pitches para el siguiente ciclo.
Como dice el libro, “el fin de un ciclo es el peor momento para juntarse a planear el siguiente, porque todo el mundo está muy ocupado en terminar sus proyectos y tomando decisiones de último minuto para entregar a tiempo”.
Además, este tiempo es perfecto para que salgan cosas bacanes que tal vez no se harían en un pitch. Por ejemplo:
- Matías programó un buildpack en C que genera un binario ejecutable para arreglar los deploys automáticos (que eran muy ineficientes).
- Saratscheff creó a Alfred, nuestro bot que nos asigna parejas cada dos semanas para conversar y conocernos más (especialmente necesario durante la cuarentena, en que entraron 22 personas al equipo y nunca nos habíamos visto).
- Jota arregló el pipeline de los tests para que corrieran más rápido en paralelo.
- La Chau rehizo las vistas asociadas al home que estaban con diseño legacy (y bastante feas).
- Boris creó una plataforma para agrupar las cosas bacanes que ha desarrollado la comunidad de Fintual.
Y como éstos, muchos desarrollos se han hecho en estas semanas de completa independencia.
¿Cómo ha sido la experiencia?
Estamos en nuestro décimo ciclo y la experiencia con Shape Up ha sido muy positiva. 84 pitches han pasado la Betting Table, cualquier persona del equipo puede shapear y los devs tenemos mayor libertad y responsabilidad.
Hemos aprendido en el camino gracias a las retrospectivas que mantuvimos de Scrum. En éstas discutimos qué salió bien, qué salió mal y action items para mejorar. De las reuniones han salido medidas como aumentar el cooldown de dos a tres semanas, que los desarrolladores part-time solo estén en pitches de seis semanas y que el apetito de un pitch no se puede cambiar en la Betting Table.
FAQ
Cierro con algunas preguntas comunes sobre cómo usamos esta metodología.
¿Cómo lo hacen con las tareas cortas o los bugs urgentes?
Para eso tenemos a nuestros superhéroes: el equipo de soporte. Este rota entre los devs y sigue los mismos tiempos que los ciclos de building.
¿Es Shape Up para todos?
Tal vez no. Es importante considerar el contexto de la empresa.
Pero si sientes que algo está mal con la metodología que usan en tu equipo de desarrollo o que las features demoran mucho más de lo planeado, vale la pena darle una oportunidad. No tiene que ser all-in como lo hicimos nosotros (adiós Trello, adiós tarjetas, adiós reuniones). Puede ser más paulatino y en el libro dejan algunas maneras para empezar con Shape Up.