Lo que la mayoría de los "gurús" ágiles no entienden sobre el desarrollo de hardware

La metodología Ágil, arraigada en el mundo del desarrollo de software, ha sido aclamada como una fuerza transformadora en la industria tecnológica. Sin embargo, a medida que nos adentramos en el desarrollo de hardware y electrónica, la aparentemente suave adaptación de los principios Ágiles encuentra un laberinto de desafíos y malentendidos. En nuestra primera entrega de esta exploración de tres partes, analizamos los desafíos Ágiles que surgen de las diferencias entre el desarrollo de hardware y software. En este artículo, examinamos los mitos propagados por los "gurús" Ágiles.

Antes de adentrarnos en las complejidades de Ágil en el desarrollo de hardware electrónico, es importante aclarar que nuestra intención no es desacreditar a los entrenadores y consultores Ágiles. Reconocemos y apreciamos sus buenas intenciones y entusiasmo por ayudar a los clientes a cosechar los beneficios de las metodologías Ágiles. Aunque algunas críticas pueden surgir de un entendimiento limitado de las sutilezas del hardware, la intención no es criticar, sino adaptar los principios Ágiles de manera efectiva para satisfacer las demandas específicas del desarrollo de hardware. Nuestro enfoque está en personalizar las tácticas Ágiles para aprovechar sus beneficios en este contexto único, modificando el enfoque pero preservando los principios.

Mito #1: Debes Mantenerte Flexible y Adaptarte

Los gurús de Agile correctamente exaltan las virtudes de la ejecución iterativa, los bucles de retroalimentación, y la rápida adaptabilidad que han prosperado en el ámbito digital del software. Sin embargo, la transición de estos principios al paisaje tangible del hardware y la electrónica introduce una capa de complejidad no encontrada en el espectro puramente digital. Las soluciones físicas, a diferencia de sus contrapartes de software, necesitan estar "terminadas" para ordenar partes, fabricar moldes y cumplir con las estrictas necesidades de fabricación. El llamado de Agile a un cambio constante choca con la naturaleza implacable del efecto dominó del hardware cuando incluso se requieren cambios menores tarde en el proceso.

En respuesta, modificar Agile para el desarrollo de hardware requiere un cambio de paradigma. No se trata de modificaciones incesantes, sino de adaptaciones estratégicas e informadas y de prototipado. Estas se basan en ciclos rápidos de aprendizaje y ejecución que buscan maximizar el valor dentro de las limitaciones de tiempo, presupuesto y recursos. La danza entre la agilidad de Agile y las demandas de la finalidad del producto físico requiere una planificación de iteración más consciente y un profundo compromiso con la reducción de riesgos a lo largo del proyecto.

Mito #2: Debes Desarrollar un Prototipo Funcional en Cada Sprint

Mientras que desarrollar un prototipo completamente funcional cada dos o tres semanas en un "sprint" es a menudo propagado por los puristas de Agile como un "debe" universal para ser Agile, la factibilidad práctica de este enfoque se desmorona ante la realidad del desarrollo de hardware y electrónica (y el presupuesto). La idea de construir algo, demostrar progreso y usar este resultado para obtener retroalimentación técnica y comercial valiosa para informar tu próxima iteración es correcta. Sin embargo, cada proyecto de hardware es una entidad distinta con sus propios objetivos, dependencias, restricciones de tiempo de entrega, áreas de innovación necesarias y riesgo. Y cada proyecto merece su propio enfoque único para el prototipado y el aprendizaje.

Para adoptar verdaderamente el desarrollo de productos de hardware ágil, los equipos deben abandonar la mentalidad de que una sola solución sirve para todos. En su lugar, deben realizar un examen cuidadoso de las necesidades del proyecto y luego colaborar para derivar una estrategia creativa, de aprendizaje y de prototipado. Es importante reconocer que un "prototipo" puede ser cualquier resultado demostrable que varíe desde un folleto preliminar hasta una maqueta de espuma (como el famoso prototipo de iPod de Steve Jobs que cabe "1000 canciones en tu bolsillo"), e incluso incluir prototipos parcial o totalmente funcionales.

Mito #3: Añadir Historias al Backlog y Simplemente Empezar

Una fortaleza inherente de las metodologías Ágiles radica en su capacidad para iniciar un proyecto mucho más rápido que los enfoques tradicionales de cascada. De hecho, para proyectos de hardware electrónico Ágiles, hemos visto una reducción significativa en el período desde la identificación del concepto hasta el inicio del desarrollo. Este período, que a menudo se extendía por muchos meses o incluso años bajo un enfoque tradicional por fases, se ha condensado a cuestión de semanas o días con los métodos Ágiles. Por supuesto, parte de este resultado dramático es cómo definimos "inicio del desarrollo".

Para el software, esto es directo. Los gurús de Agile promueven la escritura de Historias de Usuario para definir las características del software, priorizarlas en un backlog y dar inicio a un Sprint. Sin embargo, en hardware, al menos se necesita un mínimo de planificación previa para guiar el proyecto en la dirección correcta con un entendimiento de la arquitectura, los atributos clave deseados, las restricciones y otros factores. Este esfuerzo previo puede parecer que choca con los principios de Agile de "el software en funcionamiento es la principal medida del progreso" y "bienvenidos los cambios en los requisitos, incluso tarde en el desarrollo".

La reconciliación radica en encontrar un equilibrio adaptando tácticas comúnmente entendidas de Agile al frente del desarrollo de productos. La gestión de proyectos Agile para hardware permite una iniciación rápida alineándose con la intención estratégica del proyecto y aceptando muchos más desconocidos que los enfoques tradicionales. Los equipos pueden entonces colaborar usando el aprendizaje iterativo de Agile para definir la solución óptima, junto con una mentalidad abierta a cambios estratégicos que mejoren el valor del producto mientras se mantienen dentro de las restricciones de tiempo y recursos.

Mito #4: Definir Todos Tus Elementos de Trabajo como Historias de Usuario

Una directriz crítica que muchos gurús de Agile promulgan es que todo el trabajo de desarrollo debe definirse como Historias de Usuario. El consejo continúa diciendo que los componentes del sistema, interfaces, otros ingenieros, etc., deben ser tratados como "Usuarios". Este consejo tiene a la mayoría de los desarrolladores de electrónica y hardware rascándose la cabeza y luchando por cumplir.

Una razón principal por la que los equipos de software han adoptado tan fácilmente las prácticas Agile es porque documentar las necesidades del cliente con documentos de requisitos tradicionales y casos de uso detallados era muy derrochador y agregaba poco valor al equipo. ¿Por qué no simplemente declarar lo que el usuario está tratando de hacer, escribir una Historia de Usuario para documentar la característica y luego tratar esto como una tarea de desarrollo? No solo se auto-documenta, sino que si estas historias se priorizan y validan constantemente con los clientes, tenemos el sistema cerrado perfecto para responder al cambio y optimizar el valor. ¡Genial!

Este intento de escribir Historias de Usuario directamente como elementos de trabajo para el desarrollo de hardware mientras se las rastrea hasta resultados valiosos para el cliente es a menudo el punto de quiebre de Agile para muchos equipos de hardware. Definir hardware es simplemente diferente a definir software. Los Documentos de Requisitos del Producto (PRDs) tradicionales y las especificaciones funcionales no solo son reconfortantes para los desarrolladores de hardware, sino que también proporcionan los detalles necesarios para desglosar y entregar su trabajo. Pedir a los desarrolladores que escriban una Historia de Usuario como: "Como una unidad de procesamiento, necesito regulación de voltaje para asegurar una entrada limpia..." derrota el propósito de capturar el valor del cliente a través de Historias de Usuario y añade desperdicio sin valor que los desarrolladores de software estaban tan ansiosos por eliminar con los principios de Agile.

Como Mike Cohn, un líder de pensamiento temprano en Agile para software, lo define: "Una Historia de Usuario es una descripción corta y simple de una característica contada desde la perspectiva de la persona." La palabra clave aquí es "persona". Agile para equipos de hardware puede obtener un valor significativo de escribir Historias de Usuario pero debe usarlas para capturar las necesidades del cliente de personas, no definir elementos de trabajo. Estas historias deben luego ser traducidas a atributos del producto y elementos de trabajo relacionados que satisfagan los resultados deseados con técnicas que tengan sentido para los desarrolladores de hardware.

Mito #5: Debes Tener Miembros del Equipo Dedicados

Una encuesta de LinkedIn realizada por Vitality Chicago mostró que el 54% de los practicantes de Agile dicen que tener un equipo dedicado a Scrum o Agile (lo que implica miembros del equipo dedicados) es una regla esencial de Agile. Aunque no se discuten los equipos dedicados en el Manifiesto Ágil, los gurús de Agile a menudo tratan esto como una regla, y es difícil argumentar que no habría muchos beneficios al tener miembros del equipo enfocados 100% en un proyecto. Habría pocas excusas para no cumplir con los compromisos, nada que distraiga el éxito, y nadie diciendo: "¡Este otro proyecto tiene mayor prioridad esta semana!"

Sin embargo, si alguna vez has trabajado en un entorno de desarrollo de hardware, sabes que contar con miembros dedicados en el equipo sería un lujo que pocas organizaciones pueden permitirse. La naturaleza del desarrollo de hardware es que arquitectos, diseñadores líderes y otros expertos en la materia (SMEs) a menudo son necesarios en múltiples proyectos. Una empresa podría tener un experto en frecuencia de radio que se llama cuando se necesita su experiencia, un especialista en diseño de disposición que se necesita en momentos clave, etc. Los equipos de desarrollo de hardware aún pueden adoptar y aprovechar los métodos Ágiles, pero contar con miembros dedicados en el equipo típicamente no es una opción. Por lo tanto, contar con un enfoque de gestión de recursos que apoye a Ágil es crítico para el éxito a largo plazo de Ágil.

#Mito 6: Ágil es la Suma de sus Roles Definidos, Rituales, Ceremonias y Vocabulario

Dos equipos están trabajando lado a lado en una empresa: un equipo de hardware utilizando un enfoque tradicional de cascada y un equipo de software utilizando métodos Scrum. Un desarrollador de hardware pasa por el lado de la sala de conferencias donde los desarrolladores de software están reunidos en círculo y escucha, "Ok, bienvenidos a nuestro standup. Durante el último sprint, tuvimos dificultades con las estimaciones de puntos de historias de usuario y los criterios de aceptación. Nuestro scrum master compartió nuestro último burn-up y facilitó una retrospectiva para abordar los problemas en nuestro grooming de backlog para que podamos aumentar la velocidad. Vamos a hacer un puño-a-cinco sobre cómo nos sentimos respecto a los cambios." Una variedad de configuraciones de puños y dedos se levanta rápidamente.

El desarrollador de hardware, aunque intrigado, no puede evitar sentirse un poco perplejo por este ritual extraño y la abundancia de términos desconocidos, preguntándose cómo estas metodologías Ágiles podrían posiblemente traducirse a su mundo de desarrollo de hardware tangible. "¿Me he topado con un culto?!" se pregunta a sí mismo.

A menudo, los gurús de Agile están tan inmersos en el lenguaje y la cultura de Agile para software que creen que los equipos de hardware deben adoptar las mismas ceremonias, roles, herramientas y lenguaje para ser verdaderamente "ágiles". Irónicamente, el primer principio en el Manifiesto Ágil afirma, "Individuos e interacciones sobre procesos y herramientas". Creo que podemos construir sobre esto y afirmar aún más, "Individuos e interacciones sobre procesos, herramientas, rituales y dogmas." Aunque es crítico para el éxito el ponerse de acuerdo en el lenguaje, formatos de reuniones y actividades específicas para construir una mentalidad ágil y una forma sistemática de trabajar, no lo es adoptar los rituales y vocabulario específicos de Scrum o Agile para software. Los equipos de hardware deben mirar el propósito y la intención de cada elemento ágil, ceremonia y rol y determinar qué y cómo cada uno puede satisfacer mejor sus necesidades.

Tendiendo un Puente en la Brecha Ágil-Hardware

Mientras contemplas si un enfoque Ágil es adecuado para tus esfuerzos de desarrollo de hardware y electrónica, la "sabiduría" convencional propagada por gurús Ágiles bienintencionados a menudo se queda corta al guiar el enfoque más matizado y adaptativo necesario para el desarrollo de productos físicos. El camino hacia una implementación Ágil exitosa en hardware implica una mezcla reflexiva de flexibilidad, preparación previa, planificación iterativa y un enfoque concienzudo para converger en la solución más valiosa posible en el menor tiempo.

En el segmento final de nuestra serie de tres partes, profundizaremos aún más en cómo aprovechar las ventajas del Agile modificado para el desarrollo de hardware electrónico, todo ello manteniendo los principios fundamentales de la metodología Agile. ¿Te interesa explorar el tema con más detalle? ¡Mira el webinar!