Shape Up: mi elección para gestionar proyectos (adiós Scrum)

Si hay algo que debo agradecer a las redes sociales es que me permiten experimentar -con cierta frecuencia- “momentos ahá” o “momentos eureka”. Esos espacios de alta euforia en donde un pedacito de contenido hace clic con los retos laborales que enfrento.

Twitter, Indie Hackers y Reddit son mis redes favoritas para encontrar ese tipo de contenido. LinkedIn, Instagram y TikTok son las peores.

Hace algunos días experimenté un momentazo ahá que cambió radicalmente mi visión sobre cómo gestionar un proyecto de desarrollo de software.

No sé si es una metodología o un framework. Lo único que puedo asegurar es que “Shape Up” es coherente. Busca que los equipos se enfoquen efectivamente en construir algo y no en cumplir con reuniones, formatos, puntos o cualquier otra artimaña inventada por las gerencias para controlarles.

Quiero contarte más sobre Shape Up, pero antes te comparto mi contexto.

Liderar proyectos es gran parte de lo que hago

Una de mis cualidades es que soy muy organizado.

No concibo otra manera de ejecutar mi trabajo que no sea bajo un profundo orden y prolijidad.

Por eso creé CAPS, mi metodología personal de productividad con la que mantengo mi trabajo bastante organizado, sin embargo, no está enfocada en coordinar equipos.

Para estos casos aplico una fórmula bastante simple:

Un tablero en algún software de gestión de proyectos como Notion o Trello.
Etapas basadas en Kanban: por hacer, haciendo y hecho.
Y un canal de Slack para comunicarnos.

Es simple, pero funciona.

Todo cambió cuando ingresé a la industria del desarrollo de software.

Por algún extraño motivo la mayoría de desarrolladores tienen a Scrum como el santo grial de la organización y la gestión de proyectos.

Y si bien creo que Scrum no es necesariamente malo, tampoco creo que ayude a que los equipos sean más ágiles. Por el contrario, estoy convencido que los hace más lentos y desmotivados.

Juro que no sentí un rechazo tan grande como cuando cuestioné a Scrum en una mesa con desarrolladores. Ni siquiera cuando cuestioné a CrossFit en mi antiguo box. Ósea, es algo más parecido a una secta que a un equipo.

Aún así, tampoco tenía una alternativa que pudiese recomendar, por lo que todo quedaba ahí: en cuestionamientos.

Scrum es un cáncer

Me sentí escuchado cuando leí un tuit de Santiago Pino en donde tachaba a Scrum de cáncer.

Y ojito que Santiago no es cualquier persona, es un referente de la IA y el machine learning con más de 25 años de trayectoria escribiendo código.

Estos son sus argumentos para semejante comparación:

Nada inutiliza a un equipo de software como lo hace Scrum.
Intentaron convencerme de que el póquer es una herramienta de planificación, no un juego.
Nos hicieron asistir a las “ceremonias”, un nombre elegante para un montón de reuniones: stand-ups, groomings, plannings, retrospectives y el Scrum del Scrum. Pasamos más tiempo hablando que haciendo.
Prohibimos las computadoras portátiles en las reuniones. Tuvimos que ponernos de pie. Nos pasamos una pelota para que todos prestaran atención.
Pasamos más tiempo estimando puntos que escribiendo software. Los puntos miden la complejidad, no el tiempo, pero tuvimos que decidir cuántos puntos caben en un sprint.
Tuve que usar tallas de camisetas para estimar software.
Medimos cuánto costaba entregar un punto y luego redactamos contratos en los que los clientes pagaban por un paquete de “500 puntos”.
La gerencia se desquebrajó cuando descubrió que 500 puntos en un proyecto no eran lo mismo que 500 puntos en otro proyecto. Tuvimos muchas reuniones para solucionar este problema.
Imagina tener un gerente, un scrum master, un product owner y un tech lead. Había que responder a todos y a ninguno simultáneamente.
Pagamos a personas que nos decían si estábamos “quemando puntos” lo suficientemente rápido. ¿Los puntos no medían la complejidad y no el tiempo? No importó.

Coincido plenamente con este análisis y lo complemento así:

Exceso de reuniones: Es intolerable la cantidad de reuniones que tienes que cumplir. Desde el daily (que no lo veo mucha utilidad) hasta las retrospectivas que son espacios para comer pizza y en donde raramente sale un accionable. De hecho, todos esos “aprendizajes” se terminan tan rápido como la pizza.
Ventana de tiempo de desarrollo muy corta: Entiendo que el objetivo es incrementar el valor del producto lo más rápido posible, pero 15 días es muy poco tiempo para hacer algo importante y que a la vez tenga cierta calidad.
Necesidad de una hiper definición: No conozco a equipos que logren terminar con sus desarrollos en los 15 días de cada sprint. Por lo general las pruebas funcionales quedan por fuera. Esto incrementa la ansiedad y baja la moral. Y si por algún motivo terminan dentro de los 15 días es porque el PO se trasnochó escribiendo las historias de usuario a un nivel de detalle que no podría escalar. En esta ecuasión, alguien siempre sufre.
Scrum Master: Esta posición demuestra lo burocrático y lento que es Scrum. Imagínate que hay alguien que tiene que hacer todo el papeleo y la logística para que esto funcione.

Entonces, ¿por qué se usa Scrum?

La respuesta es simple: Scrum existe para las gerencias, no para los equipos.

No es un framework de trabajo colaborativo. Peor aún es agilismo. Es simplemente una herramienta para que los gerentes controlen a sus equipos y sientan que están liderando los proyectos.

Estoy bastante convencido de que Scrum no es útil, pero volvía a encontrarme sin una alternativa para recomendar.

Bueno, eso hasta hace poco…

Shape Up: la propuesta de Basecamp para gestionar proyectos

Vuelvo a mi momento ahá.

Hace algunos días encontré este video en Twitter.

Inmediatamente me llamó la atención porque:

Estrategia: Las 3 personas que están agregadas a este espacio están coordinando la estrategia de dos productos. Esto es fascinante porque la estrategia es posiblemente la parte más difícil de gestionar de cualquier proyecto. Es bastante subjetiva y usualmente se discute en reuniones abiertas y no en un tablero de forma asíncrona.
Todo en uno: En una sola vista y posiblemente solo a 3 clics de profundidad están todos los recursos asociados a la estrategia de varios años atrás. Esto es un hito de organización bastante difícil de conseguir y habla muy bien del UX/UI de Basecamp.
Términos nuevos: Escuché sobre “ciclos”, “pitches” y “apetitos”. Esto no es Scrum. Esto no es nada que haya escuchado antes. Esto es nuevo y estoy gratamente intrigado.
Vi un pitch colaborativo: Un pitch es lo más parecido a un PRD pero está creado por estas 3 personas. Es colaborativo. En Scrum el PRD es responsabilidad del PO y si éste no es capaz de agregar todos los requerimientos de los stakeholders de forma clara, entonces se genera un problema. Esta dependencia en una sola persona incrementa el riesgo de que algo salga mal.
Vi un tablero de seguimiento simple: Los tableros de shaping de Basecamp y Hey! son muy sencillos se seguir. Son básicamente Kanban. No puedes perderte. Esto dista muchísimo de los tableros que usualmente se crean en Scrum con decenas de etapas, controles, registros y más.

Lo primero que pensé es que este tablero estratégico coordinaba las características que se iban a incorporar al producto a un nivel muy alto (después de todo estoy viendo un tuit de uno de los fundadores) y que después de elegidas estas funcionalidades se las iban a enviar a sus equipos para que las desarrollen en Scrum.

Pero estaba equivocado (por fortuna). Esto es es lo que me respondió Jason cuando le pregunté:

Scrum? You mean scum?

¡Qué respuesta tan épica! Me sentí aliviado y conectado. Jason no solo tenía mi atención, en este punto tenía mi devoción.

Ingresé al enlace y descubrí “Shape Up”, un proceso con el cual Jason y sus equipos desarrollan software, desde el planteamiento estratégico hasta la ejecución.

Toda esta filosofía (porque para mi va más allá de un simple proceso) fue creada desde la experiencia de crear Basecamp, un software de gestión de proyectos, y que fue perfeccionándose durante años hasta llegar a ser un libro.

Shape Up funciona, en términos generales, así:

Analicemos todo el proceso:

Shaping the work (dar forma al trabajo)

Antes de que cualquier requerimiento vaya a un equipo productivo se lo “da forma”. En este espacio un grupo de seniors definen los elementos clave de los nuevos proyectos. Buscan un nivel correcto de abstracción: que sean lo suficientemente concretos como para que los equipos productivos sepan que hacer, pero lo suficientemente abstractos como para que ellos mismos resuelvan los detalles.

Quiero destacar lo siguiente:

Se involucran hasta los fundadores de la compañía. Y tiene sentido. Se está definiendo la estrategia del producto y no puede ser “tercerizada” a un PO, que es más parecido a un secretario que a un stakeholder.
Existe un solo documento para cada proyecto. Se llama pitch y tiene toda la información de lo que se quiere desarrollar, desde la definición del problema hasta bocetos de las posibles soluciones. No está dividido por historias de usuario o tareas técnicas, eso ya es responsabilidad total de los equipos productivos.
Se define el “apetito”, un concepto fascinante. En lugar de preguntar cuánto tiempo llevará hacer algún trabajo, se pregunta: ¿Cuánto tiempo se le quiere dedicar? ¿Cuánto vale la idea? Lo que se va ajustando, entonces, es el nivel de expectativa frente al proyecto y con cuál resultado los equipos se sentirán satisfechos.

Este es el objetivo de esta parte del proceso: delimitar el problema y diseñar el esquema de una solución que se ajuste a las limitaciones del apetito.

Ciclos de 6 semanas

Seis semanas son tiempo suficiente para construir algo significativo de principio a fin y lo suficientemente corto como para que todos puedan sentir que la fecha límite se avecina, así que deben usar el tiempo sabiamente.

Los pitches son añadidos a los distintos ciclos de desarrollo con algunas consideraciones interesantes:

No se microgestiona el tiempo. No se cuentan las horas ni se hacen cuestionamientos sobre lo que se hace en el día a día. No hay reuniones diarias (dailies). No hay control.
En ese sentido, los equipos productivos son totalmente independientes, mientras que los equipos encargados de crear más pitches se enfocan en crearlos cada vez mejor y no en controlar o microgestionar a otros.
El resultado es que la hoja de ruta (roadmap) del producto no se cambia cada 2 semanas.

En este escenario se le da más importancia al resultado. Las gerencias se dicen a sí mismas: “si este proyecto se lanza después de seis semanas, estaremos muy felices. Sentiremos que nuestro tiempo fue bien empleado.”

¡Simplemente espectacular!

Empoderar a los equipos

En “Shape Up” los equipos tienen total confianza. Se le entrega la responsabilidad de la producción a un pequeño equipo integrado por diseñadores y programadores. Ellos:

Definen sus propias tareas.
Definen sus propias reuniones.
Realizan ajustes al alcance de los pitches.
Toman decisiones sobre los desarrollos.
Y, principalmente: colaboran de forma asíncrona.

Para trabajar se les pide crear porciones verticales del producto una a la vez. Esto es completamente diferente de otras metodologías, donde los gerentes dividen el trabajo y los programadores actúan como “receptores de tickets”.

Juntos, estos conceptos forman un círculo virtuoso:

Cuando los equipos son más autónomos, los directivos dedican menos tiempo a gestionarlos.
Al dedicar menos tiempo a la gestión, pueden “dar forma” a mejores proyectos.
Cuando los pitches están mejor estructurados, los equipos tienen límites más claros.
Cuando los equipos saben que hacer, tienen más autonomía.

En este círculo está el verdadero valor de “Shape Up”. Aquí está su momento ahá.

Entiendo que para muchos CEOs el dar este tipo de confianza a sus equipos puede ser desafiante. Sin embargo, las personas profesionales van a buscar una autorregulación.

Recuerdo una experiencia interesante cuando organicé uno de los meetups de H/F. Conversábamos con mi equipo sobre la mejor forma de ofrecer cerveza gratuita a quienes nos visitaban. Nuestros preconceptos nos hacían pensar que debíamos repartir una cerveza a cada asistente o darles una especie de ticket para que las intercambien después.

Finalmente decidimos crear una mesa de cervezas libre y gratuita. Cada asistente podía acercarse y tomar cuantas cervezas quisiera en cualquier momento. Mi miedo era que alguien de forma abusiva tome muchas, sin embargo, el grupo se autorreguló y hasta sobraron cervezas después del evento.

Este comportamiento está asociado al efecto de la reciprocidad y la norma social de la equidad, bajo el que las personas tienden a autocontrolarse para no parecer egoístas o abusivas, y para mantener el equilibrio social y la equidad dentro del grupo.

Este efecto psicológico, sumado a la escala de valores y principios de cada persona y la inherente responsabilidad de asumir un trabajo, aseguran que los equipos autónomos efectivamente cumplan con sus objetivos sin la necesidad de un control excesivo.

Apuntando al riesgo

“Shape Up” no se enfoca en el riesgo de desarrollar algo incorrecto. El único riesgo que busca minimizar es el de no terminar a tiempo. Por definición, una compañía debería perfeccionar su capacidad de elegir mejor las próximas características a desarrollarse solo cuando haya perfeccionado su capacidad de ejecutarlas a tiempo.

Para minimizar el riesgo de estancamiento en cada parte del proceso se busca:

Shaping the work: Resolver preguntas abiertas antes de comprometer el proyecto a un plazo determinado. No se entrega un pitch a un equipo cuando todavía existen dudas o interdependencias enredadas.
Planificación: Limitar las apuestas a seis semanas. Si un proyecto no se logra terminar, de forma predeterminada no obtiene una extensión. Este “disyuntor” garantiza que no se envíe algo que todavía necesita repensarse.
Desarrollo: Integrar el diseño y la programación lo antes posible. En lugar de desarrollar muchas piezas desconectadas y esperar que funcionen al unirlas, el equipo secuencia el trabajo desde las piezas más desconocidas hasta las menos preocupantes, aprendiendo en el camino e integrando esos aprendizajes cuanto antes.

Conclusión

Shape Up es la primera alternativa confiable, coherente y organizada que encontré para Scrum. Estoy convencido que es aplicable para todo tipo de proyecto (no solo para el desarrollo de software) porque busca un objetivo máximo: crear y entregar valor.

Más allá de las comparaciones con Scrum y otras metodologías o frameworks de trabajo colaborativo, me llama la atención porque empodera a los equipos y divide la responsabilidad de los resultados en varias personas.

Mi camino de aprendizaje con Shape Up recién inicia. Estoy seguro que voy a seguir escribiendo sobre esta metodología (proceso, framework, filosofía, teoría…) porque no solo voy a terminar de leer su fantástico libro, sino que la voy a aplicar cuanto antes en alguno de mis proyectos.