Sobre design thinking, agile y todas esas cosas

Acabo de leer este artículo, que está bien pero creo que no da en el clavo.

Desde hace algún tiempo, y para una tipología de proyectos amplia (no solo software), se viene diciendo que la planificación en cascada (waterfall) no tiene sentido. Y creo firmemente que es verdad. Tiene dos problemas: (casi) siempre hay retrasos y, aún peor, no está claro que se resuelva el problema que hay que resolver.

Es muy difícil, en un proyecto largo, ser clarividente y tener una planificación detallada y acertada de lo que va a pasar a lo largo de todo el proyecto. Las necesidades cambian y los tiempos de ejecución de las tareas tienen demasiada incertidumbre. Por eso surge agile y dentro de agile scrum, que buscan solucionar estos dos problemas del waterfall.

Mi experiencia es que scrum funciona. Pero solo funciona si se hace bien, cosa complicada porque agile (y design thinking, ahora hablo de él) implica un cambio en la forma de pensar, un cambio de mentalidad. Son los más difíciles de hacer. Los detractores de scrum simplifican diciendo que en scrum no se planifica o que los plazos dan igual; nada más lejos de la realidad. En scrum sí se planifica, con mucho más detalle de hecho: cada cosa que hay que hacer (historia de usuario) debe estar lo suficientemente bien definida como para que se pueda descomponer en subtareas que se puedan estimar y acometer dentro de un sprint. Lo que cambia es el momento de definir esas historias de usuario, que sólo se definen bien cuando se acerca el momento de hacerlas. Definir qué hay que hacer y priorizarlo es el trabajo del product owner. Estimar es trabajo del equipo. Y se planifica, de hecho se planifica en detalle al principio de cada sprint. El sprint es inflexible, pero como se puede repriorizar al principio de cada sprint, el hacer el trabajo que hay que hacer y no otro está garantizado.

¿O no? ¿Cómo se decide qué es lo que hay que hacer? Aquí entra el design thinking. Para mí, design thinking no va de resolver problemas. Resolver problemas debería ser algo fácil (mejorar la capacidad de resolver problemas debería ser uno de los objetivos de todo sistema educativo), estamos entrenados para ello desde pequeños. Pero lo que se nos enseña a resolver son problemas que decide otro, los enunciados vienen dados. Lo difícil, lo verdaderamente importante es resolver el problema adecuado: ahí es donde entra el design thinking.

El el artículo que citaba al principio lo menciona como una de las fases del design thinking: empathize, define, ideate, prototype, test. Para mí eso es darle demasiado bombo a lo que es realmente design thinking. La fases de empatizar y definir sólo so hacen una vez, el resto son cíclicas. Y por eso definir es tan importante. De nada sirve tener una solución perfecta para un problema que no necesita ser resuelto. Scrum permite estar equivocado durante un solo sprint. Design thinking permite definir bien el problema.

Se complementan.