Agile en videojuegos pero sin vender humo

5 min readMar 27, 2024

El desarrollo de videojuegos agrega numerosas disciplinas. Desgraciadamente, hemos heredado las problemáticas de cada una de ellas; como por ejemplo la precariedad de las industrias artísticas o los procesos de desarrollo de software dañinos. Hablemos de Scrum.

¿Qué pasa con Scrum?

¿Quien no ha escuchado “si no sigues la guía de Scrum, no estás haciendo Agile”? Agile no se puede hacer porque es un adjetivo; Agile es… una pantera. Desgraciadamente, en muchas organizaciones, hemos heredado la cultura corporativa tóxica de las malas empresas de software, que poco o nada tiene que ver con lo que promulgaban los firmantes del manifiesto hace ya 23 años. Volvamos a ellos:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

La verdad es que planificar cada 2 semanas lo que se va a hacer, estimando de manera cuestionable con puntos de historia, para luego muchas veces no poder entregar a producción al final de la iteración, no parece muy ágil.

También, solo hacer una retro cada 2 semanas puede ser un síntoma de una mala comunicación y una mala respuesta a los problemas. Está bien hacer una retro si te hace falta, pero quizás el end-goal del equipo es poder reaccionar a los problemas más de una vez cada 2 semanas. ¿Y qué pasa cuando el problema es la burocracia de Scrum?

Este uso que se le da comunmente Scrum es literalmente el opuesto a la intención de las metodologías ágiles: Queremos tener menos burocracia absurda en nuestros equipos; queremos tener equipos empoderados con capacidad de tomar decisiones; queremos no tener que tirar semanas de trabajo porque nos enteramos tarde que no sirve y, sobre todo: queremos mejorar cada día.

Entre toda la industria de venta de certificados de Scrum y humo hay una verdad: no se puede tener éxito en el desarrollo de un videojuego si no se siguen las prácticas adecuadas de cada disciplina. Dichas prácticas varían en cada proyecto y en cada contexto, pero Scrum no te da esas herramientas.

¿Entonces qué metodología seguimos?

Ninguna; todas; un poco de cada una; ¡lo que te haga falta! Las metodologías ágiles nacieron de personas alejadas de la academia que vieron los problemas que había en la industria del software de su momento: proyectos que no salían y que si salían no servían. No te hace falta un framework como Scrum (o cualquier otro). Cuando nos acoplamos fuertemente a un framework, ya en el código o en los procesos, todo se hace mucho más viscoso.

¿Creéis como equipo que hacer dailies puede veniros bien? Intentadlo; si sirve continuad hasta que deje de servir, si no, parad y reevaluad. Haced esto para cada proceso y actividad del equipo. Observad, probad, valorad, iterad. Los grandes cambios se hacen paso a paso.

Si tienes autoridad sobre un equipo, tu objetivo debe de ser que ese equipo tenga autonomía, y eso implica en decidir los procesos. La inmensa mayoría de personas que se dedica a hacer videojuegos es gente con una pasión y unas ganas de aprender enormes; sólo en los lugares en los que se les empodere habrá equipos de desarrollo verdaderamente efectivos. No seas un cuello de botella. Reduce el bus factor.

Si el equipo no tiene las herramientas necesarias para tener autonomía, dáselas. Empodera al equipo y luego como persona responsable dedícate a símplemente desempatar y facilitar.

Reducir el ciclo de Feedback

Otro de los objetivos principales de un equipo Agile es reducir el ciclo de feedback: ¿Cuánto tiempo pasa desde que se idea una feature hasta que la pueden probar les jugadores? ¿Cada cuanto se mergea el proyecto con el resto del equipo? ¿Cómo de rápido nos enteramos si hemos roto algo? ¿Cómo de rápido sabemos si el juego es divertido? ¿Cuánto tiempo tardamos en cambiar un proceso que no funciona?

¿Y cómo reducimos el ciclo de feedback? Me voy a tomar la libertad de adaptar un texto de Ron Jeffries:

Produce running, tested, working, integrated videogames every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day.
Keep the software design of that videogame clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible.
Use the current increment of videogame as the foundation for all your conversations with every stakeholder. Speak in terms of what’s ready to go, and in terms of what they’d like you to do next.

Y sigue la misma filosofía para los procesos de tu equipo.

Leyendo un artículo en 5 minutos no voy a mejorar. ¿Qué hago?

Los grandes cambios se hacen paso a paso.

Observad, probad, valorad, iterad.

Desgraciadamente, hay un estigma enorme respecto al agilismo. En todo caso, hay mucho oro y pragmatismo entre toneladas de humo y dogmatismo. Sólo hay que excarvar un poco.

Yo no he dicho ni voy a decir nada nuevo sobre este tema, pero puedo aportar un valor único: proponerte siguientes lecturas mucho mejores que esta. Aquí van: