¿Scrum en el Diseño Industrial?

Comienzo una nueva línea de posts algo más técnicos que surgen a raíz de multitud de libros, artículos y cursos donde he aprendido la metodología Scrum, que [casi] siempre se asocia al mundo del desarrollo digital. Mis pensamientos siempre han ido en torno a generalizar su aplicación a cualquier proyecto de diseño y, en concreto, ahora quiero adentrarme en mi disciplina, el Diseño Industrial. Nunca he leído nada en la intersección de ambos mundos, por lo que todo lo que escribo es mera especulación y estoy deseando poder aumentar mi conocimiento en esta línea. Para quienes estéis menos duchos en este asunto, Scrum es -muy a grosso modo– un marco de trabajo que bebe de las metodologías ágiles en el que se rompe con la planificación tradicional de proyectos, centrando la importancia en la priorización basada en el valor, en la autogestión de equipos, en una comunicación fluida y efectiva y en la validación reiterada de las hipótesis sobre el producto. Funciona especialmente bien en el ámbito de la programación y el desarrollo digital porque estas reiteraciones (llamadas sprints) permiten lanzar versiones actualizadas del producto de forma periódica, para recibir un feedback inmediato y así, en el siguiente sprint, trabajar sobre las mejoras que implementar en la nueva versión. A pesar de que Scrum tiene sus «reglas de juego», durante varios años he intentado poner en práctica su esencia adaptada a los diferentes proyectos en los que tenía la oportunidad de coordinar a un equipo y, en el caso de aquellos de Diseño Industrial, nos encontramos con varios problemas que no podemos obviar. (Otro día hablamos de Scrum en eventos).

Diferencia primera: dificultad de validación.

Scrum vive del concepto de MVP o Producto Mínimo Viable. Se suele utilizar como ejemplo a muchas webs que, en sus versiones antediluvianas, ya saciaban la necesidad original y, a partir de ahí, se reiteró hasta los casos de éxito actuales. Como ya quizá tenemos todos muy vistas las innumerables versiones del ejemplo paradigmático del coche usado en el lean startup, me he tomado la licencia de crear una versión nueva. Básicamente explica que si alguien tiene la necesidad de, por ejemplo, escribir un documento, ésta no tiene por qué ser cubierta por un ordenador desde el primer prototipo.   ¿O sí? Si estamos desarrollando un producto, ¿es coherente desarrollar productos análogos que satisfagan el servicio pero que no sean proyectualmente comparables? Y aún más: ¿es testeable ese producto de la misma manera? Imaginemos que queremos diseñar un martillo. Sí, el servicio que queremos cubrir es el de golpear cosas. Podríamos diseñar infinidad de objetos que sirvan para golpear, desde un bate de béisbol hasta un zapato o, en efecto, un martillo, pero luego toca enfrentarse a la validación. ¿La presencia de un sprint implica que es viable que tengamos como primer prototipo un martillo de cartón? Sin ánimo de ser simplista respecto al desarrollo digital, para que el usuario testee una versión nueva de una app o una web, basta con que dicha persona acceda desde su móvil y, a partir de ahí, se sumerja en el mundo digital donde sucederá toda su experiencia (siempre con una misión, claro). En cambio, al testar un servicio o producto donde aparece el mundo real, hay factores inéditos que entran en escena: más contexto, la interacción corporal, la materia. ¿Puedo testear un martillo si no tengo un clavo al que golpear? ¿Me cansa el brazo después de una hora golpeando? ¿Probarlo durante esa hora me garantiza que siga funcionando igual de bien tras meses de uso? ¿Cómo puedo repararlo si se me rompe? Mención aparte merece el área del research; la utilización de sprints rápidos de trabajo provoca que, en ocasiones, la investigación no alcanza el grado de profundidad y madurez que debería, por la imperiosa necesidad de desarrollar prototipos cuanto antes e ir investigando a la par o incluso después de desarrollarlos. Esto realmente no es una diferencia exclusiva del producto físico porque puede aplicar en muchas áreas del diseño.  

Diferencia segunda: tiempo de ciclo.

Algo que salta a primera vista es que los tiempos de fabricación de un producto físico son inexorablemente superiores que los de «fabricación» de un producto digital. De hecho, en cierto modo ambos se van «fabricando» mientras se diseñan, con la diferencia de que el físico necesita un salto final para convertirlo en realidad. Supongamos que las tecnologías de fabricación basadas en el prototipado rápido o en pre-series industriales cortas son suficiente para desarrollar un producto que nos solucione aquella problemática (mucho suponer). Seguimos necesitando, como mínimo, tiempo de logística y transporte, amén de que no tenga mil componentes internos que debamos perseguir individualmente. Una vez oí hablar de sprints de forma desfasada según la especialidad de cada uno de los scrum teams que se podían formar. Sé que departamentalizar una metodología ágil puede chirriar en su esencia, pero hay ocasiones en las que puede ser la única opción. Imaginemos que creamos un equipo de Scrum orientado al desarrollo y otro orientado a la investigación  y que ambos funcionan de forma paralela pero desfasada («al tresbolillo» acuñaría yo), de tal forma que, aunque aún no haya terminado un sprint, se aproveche el tiempo muerto de la fabricación para empezar a desarrollar el siguiente. Esto es un contrasentido teniendo en cuenta que habría que testear el producto, recoger feedback y crear una nueva pila de modificaciones para poder empezar a trabajar sobre ello, pero podría ajustarse si realizamos un primer prototipo lo suficientemente funcional mediante fabricación digital -más rápida- y continuamos con prototipados más complejos en los que aplicar este sistema. ¿Podrían ser ambos equipos el mismo, cambiando de careta constantemente entre ambas fases? En cualquier caso, la pila de producto sería un artefacto bastante particular, porque habría que lanzar mejoras no sólo de forma incremental sino teniendo en cuenta los tiempos fijos necesarios.  

Diferencia tercera: coste de prototipado.

El tiempo es dinero y todo lo que se ha podido relatar respecto al factor tiempo, lleva un coste asociado. No sólo el tiempo de la persona diseñadora o ingeniera, que es algo fácilmente integrable en el marco de trabajo, sino de la fabricación y la logística. La fabricación digital parte con ventaja para reducir costes, pero unos acabados de mayor calidad requerirán máquinas mejores. Si entramos en fabricación de moldes, la cosa se dispara y aparece la economía de escala, por lo que Scrum se derrumba bastante. Porque en el momento en el que nos gastamos 15.000€ (y tiro por lo bajo) en un molde que fabricará centenares de unidades durante meses… ¿estamos dejando hueco a la validación del usuario para corregir futuras versiones? Me temo que no, por lo que quizá sólo podemos ser ágiles gracias a la fabricación digital y a una estimación de costes logísticos muy afinada. Todo esto sin mencionar que nuestro producto no está en tu ordenador y puede aparecer al instante, sino que necesitamos ese transporte que, como ya nos imaginamos, también requiere suplementos de coste según aumenta la urgencia. La consecuencia o posible solución para reducir constantes costes de producción es que los sprints quizá tienen que ser más largos de lo esperable con un producto digital. Es decir, una pila de producto poco llena puede no compensar una próxima reiteración y es necesario «sobrecargarla» de mejoras para que el envío a fábrica compense, en términos de costes y en términos de incremento. Otra opción sería dividir el tipo de revisión que se realiza en dos: la empática y la técnica. Si bien con la primera evaluamos aceptación y adecuación a los usuarios -como en un servicio digital-, con la segunda hacemos pruebas de resistencia, optimización estructural y otros parámetros que habrá que encajar con ese feedback de cara a la próxima reiteración. Obviamente, siempre se espera que una revisión sea de calidad pero, si los costes de fabricación son tan elevados, debe ponerse especial atención en este aspecto. Finalmente, tenemos la opción de separar los sprints en dos categorías: los importantes (todos lo son) y los muy importantes, en función de si vamos a fabricar el prototipo con tecnologías más flexibles y baratas o más avanzadas y costosas. Los sprints del primer tipo se pueden centrar en la validación del usuario y los del segundo tipo en ésta junto a la validación técnica.  

**********

Mucha divergencia y muchas cuestiones pero realmente no quiero llegar a ninguna conclusión. Son innumerables las reflexiones que he tenido y seguiré teniendo sobre si es posible estandarizar de alguna forma las reglas del Scrum al Diseño Industrial y quizá todo pasa por segmentar los diferentes (e infinitos) casos de proyecto de Diseño Industrial que podemos acometer. No es lo mismo un prototipo único funcional, un diseño expositivo con unos plazos definidos o una fabricación industrial a gran escala. De momento no tengo otro objetivo que escribir sobre todos estos planteamientos e ir completando mis secciones con nuevas ideas que considere dignas de ser compartidas.