×
×

Scrum en I+D de Hardware o producto físico

 

Introducción

Nota: se recomienda conocimientos básicos sobre las siguientes materias para un correcto entendimiento de este artículo:

Desde los años 90, el desarrollo de software ágil* ha ido ganando popularidad exponencialmente a lo largo de los años. Grandes organizaciones como ING, BBVA, Google o KING han empezado a utilizar métodos ágiles para el desarrollo de software con resultados satisfactorios. Pero… ¿Se pueden aplicar estos métodos en un ambiente de I+D de producto físico o hardware? Por mi propia experiencia, sé que no es solo posible, sino también recomendable y beneficioso para el negocio en sí, el compromiso, la colaboración, la satisfacción personal y motivación de los empleados.

El modelo de desarrollo en cascada

El desarrollo de hardware tradicional (casada o diagrama de Gantt**) se popularizó en los años 70 y 80. Se considera la manera estándar para desarrollo de hardware hoy en día. Funciona muy bien en algunos casos, pero hoy, muchas empresas lo consideran obsoleto por las siguientes razones:

  • Asume que el cliente sabe todos los requisitos desde el principio del proyecto. Pero normalmente, nuevos descubrimientos a lo largo del desarrollo fuerzan la aplicación de cambios en los requisitos iniciales. Lo cual requiere mayor flexibilidad para implementar las mejoras en el momento que se descubren, con el menor coste adicional posible.
  • Cuando pasa demasiado tiempo sin “feedback” del cliente, el plan se convierte en una receta para desarrollar algo incorrecto, a un precio desfasado y fuera de los plazos inicialmente establecidos, incluso habiendo completado las especificaciones iniciales.
  • Requiere mucho tiempo de análisis, sin “construir” nada. En algunos casos, el cambio de diseño es muy costoso cuando el proyecto pasa a “fabricación”. Esto es un problema porque probablemente el equipo va a aprender cosas durante la “fabricación”, que podrían tener un impacto en el diseño del producto.

Cuando estos inconvenientes ocurren, el proyecto será, o bien replanificado, o cancelado. El tiempo, energía y recursos malgastados en ese producto es muy perjudicial para la empresa. Sin embargo, tenemos la opción de adoptar metodologías ágiles, para así mejorar la adaptación a cambios de mercado y utilizar los recursos disponibles de manera más eficiente.

Scrum también sirve para el desarrollo de producto con HW

En este caso, hablaré sobre Scrum*** y como se puede utilizar en desarrollo de producto físico, donde el diseño, creación de prototipos y “testing” son las principales tareas para alcanzar los objetivos del proyecto.

Scrum se origina de hecho en un artículo "The New New Product Development Game" que estudia a equipos de desarrollo de hardware en empresas como Honda o Canon.

A diferencia del software, el desarrollo de producto físico en Scrum consiste en la agregación de pequeñas mejoras para un producto utilizable (acabado) al final del desarrollo. A medida que pasa el tiempo, el diseño del producto tiene más componentes, pero el producto no funciona correctamente hasta que todas las piezas están acabadas y ensambladas. El “feedback” de los “stakeholders” está más orientado a conceptos y maquetas que funcionalidad.

El mayor reto para el equipo de desarrollo es realizar pequeñas mejoras en un Sprint. Esto se debe a que es difícil tener algo “terminado” (muy importante tener una definición común y clara de “terminado”, especialmente en este contexto) donde se requiere diseño, construcción de prototipos y “testing” de una mejora en un periodo de tiempo tan pequeño.

Pero es posible descomponer el trabajo de construir un componente que tarda más de 3 o 4 semanas, en pequeños entregables (historias de usuario), de tal manera que el objetivo es posible de alcanzar en un Sprint. Existen maneras y herramientas que pueden ayudar a realizar esta descomposición de trabajo (haz click aquí para saber más sobre esto).

En cada Sprint, los objetivos van acorde con las últimas demandas del cliente/mercado, considerando el conocimiento y la experiencia obtenida del producto que estamos desarrollando. La razón por la que un equipo Scrum puede adaptarse rápidamente a casi cualquier cambio, es porque sus principios y prácticas, se basan en la transparencia, inspección y adaptación cada 24 horas (The Daily Scrum) y en cada Sprint (Sprint Review). Cuando se detecta un impedimento o una mejora en medio de un Sprint, no debería de llevar más de 24 horas en actuar y tomar una decisión basándose en el conocimiento sobre la materia en la que se está trabajando.

Dicho esto ¿Por qué empezar a utilizar Scrum? Si se es capaz de utilizar Scrum correctamente, respetando sus valores, principios y prácticas, el foco de atención del equipo de desarrollo estará exclusivamente en las tareas que estén realizando en cada Sprint y serán capaces de adaptarse a los cambios día a día. Seguirán la dirección marcada por el Product Owner, ayudándole en el camino junto con el Scrum Master, para que todo lo que se haga tenga sentido y aporte valor de negocio (business value). El equipo se sentirá propietario de su trabajo, nadie les va a indicar cómo realizarlo y serán responsables de las tareas que hagan en cada Sprint. De aquí nacerá una cultura de inspiración para innovar, deseo de explorar, disposición a tomar riesgos y romper nuevas fronteras. El equipo se convertirá en experto dentro del área en la que están trabajando. Por eso Scrum tiene sus propios valores, principios, roles, eventos y prácticas, para que, al menos las personas responsables de innovar, sean especialistas dentro de una determinada área de negocio de la empresa.

Como ya habrás leído en la guía; “Scrum se ha utilizado para desarrollar software, hardware, redes de funciones interactivas, vehículos autónomos, escuelas, gobiernos, marketing, también para gestionar el operativo de organizaciones y en casi todo lo que utilizamos en nuestra vida cotidiana, tanto individualmente, como en sociedad.”

Lo cierto es que empresas como Tesla, GoPro, Airbus y muchas otras, ya han empezado a utilizar Scrum en su desarrollo de hardware con resultados muy satisfactorios. Si ha sido un éxito en tantos ámbitos y organizaciones, ¿Por qué no lo iba a ser en la tuya?

¡Queremos vuestro feedback!

Os invitamos a darnos feedback sobre el artículo para mejorarlo o por si queréis más información acerca de Scrum en ámbitos de I+D en Hardware. Contactad con nosotros haciendo click aquí