No eres "ágil" si... modelos híbridos

Las conversaciones que he tenido con colegas, lectores de mi blog y un profesor de la Pennsylvania State University sobre tales obstáculos han generado apasionadas discusiones sobre el valor relativo y la utilidad de los modelos híbridos.

Cascada

Los métodos clásicos de desarrollo de software son como una cascada que comienza con la definición de requisitos y termina con la implementación. El trabajo se ejecuta en pasos individuales a lo largo de las etapas de esta cascada, similar al trabajo en cadena de montaje en la producción de automóviles. El producto solo es funcional cuando sale de la línea al final. En este modelo, ciertos trabajos son realizados una y otra vez por los mismos especialistas. Henry Ford revolucionó el mercado automotriz con este método.

Sin embargo, este tipo de desarrollo de software también puede fomentar todo tipo de comportamientos negativos. La razón es generalmente la incompatibilidad entre los trabajos en cadena de montaje (por ejemplo, en la producción) y los trabajos más dinámicos orientados a la investigación y el desarrollo. Un ejemplo de tal comportamiento negativo es el uso erróneo de los llamados "Stage Gates" (hitos entre las etapas individuales). A menudo los equipos simplemente siguen trabajando, aunque el método en realidad dicta que se debería esperar una decisión para un Stage Gate. El problema es que nunca terminarían a tiempo si esperaran la decisión. Los gerentes SIEMPRE saben lo que está pasando, pero prefieren no hacer preguntas. La razón normalmente no es que alguien en el proceso trabaje mal, sino más bien que el proceso en sí es malo.

Agile es diferente

Agile interrumpe esta cascada y divide el trabajo en partes más pequeñas. Estas partes más pequeñas se diseñan, desarrollan, prueban y entregan mediante Sprints cortos para obtener feedback directo. Con el "nuevo" proceso ya no hay razón para ignorar las señales de stop de los Stage Gates.

Los modelos híbridos pretenden utilizar lo mejor de los frameworks clásicos y ágiles y así adaptarse de forma óptima a la cultura y estructura actual de la organización. Querer adaptar los métodos ágiles a una organización que en realidad está diseñada para métodos clásicos es el punto donde frecuentemente se cuelan los problemas. Los compromisos necesarios suelen estar en contradicción con las premisas de los valores y principios ágiles.

Ejemplos de tales premisas en Agile son los equipos estables, la responsabilidad propia y la entrega de software funcional al final de cada Sprint. Es más fácil alejarse de estos valores y principios que cambiar la cultura y estructura de la organización. Uno de los compromisos más frecuentes (y más dañinos) se puede observar en organizaciones que continúan trabajando con equipos de composición dinámica (a menudo llamadas organizaciones matriciales). Los equipos estables requieren frecuentemente el rediseño de los límites organizacionales y una revisión más detallada de las capacidades.

Estos son los problemas típicos que, si no se abordan, pueden tentar a una organización a utilizar formas mixtas de métodos clásicos y ágiles:

Silos: Cuando los grupos individuales están separados entre sí, se necesita más planificación y coordinación para asegurar que las personas adecuadas estén disponibles en el momento adecuado, incluso en caso de retrasos. Las grandes organizaciones de desarrollo han incorporado el rol de un Scheduler (planificador de trabajo) o un Expediter (supervisor de plazos) en su organigrama para lidiar con este tipo de problemas.

Demasiado delgados: Muchas organizaciones de desarrollo sufren años de medidas de ahorro y tienen muchas menos personas disponibles de las necesarias para completar el trabajo al que se han comprometido. Los empleados trabajan activamente en varios proyectos diferentes para dar la apariencia de progreso en toda una serie de iniciativas. Cambiar entre diferentes tareas es altamente ineficiente y disminuye el valor entregado, lo que a menudo conduce a una presión aún mayor para reducir costos.

Falta de enfoque: Los líderes de las organizaciones de desarrollo a menudo sienten la necesidad de aceptar y ejecutar todos los proyectos que se les presentan. Esto también se llama el "síndrome del sí a todo". Ocurre principalmente en organizaciones que no cuentan con una gestión de portafolio sólida. En última instancia, esto significa que los equipos y empleados se ven obligados a hacer multitasking, lo que a su vez conduce a ineficiencias.

Insuficiente automatización: Nunca he conocido un método de desarrollo que no se pudiera ejecutar a pequeña escala con lápiz y papel. Sin embargo, una escala mayor se hace posible mediante la automatización. Imagina, por ejemplo, que tuvieras que escribir varios miles de pruebas de regresión a mano. Para ejecutar las pruebas, necesitarías mucho tiempo o muchas personas. Muchas personas normalmente significan también más equipos, más límites entre equipos, más jerarquía y más esfuerzo, lo que puede llevar a que se realicen menos pruebas porque hay que cumplir con un plazo o un presupuesto determinado.

Los valores y principios en los que se basa Agile son realmente importantes. Influyen en los comportamientos de tal manera que se pone más énfasis en la entrega más rápida de valor. Los cuatro valores del Manifiesto Ágil se presentan como pares. Por ejemplo, el primero de los cuatro valores dice: "Individuos e interacciones sobre procesos y herramientas". Los elementos del lado izquierdo tienen un valor mayor que los del lado derecho (aunque estos naturalmente también tienen valor). A través de los modelos híbridos, frecuentemente se crean compromisos que desplazan el énfasis de los puntos del lado izquierdo más hacia el centro o incluso de vuelta a los puntos del lado derecho.

Los modelos híbridos no son fundamentalmente malos

Pero cuando al hacerlo nos alejamos de los valores y principios ágiles fundamentales en lugar de abordar temas difíciles en la organización, a menudo se trata solo de maniobras evasivas. Estés de acuerdo o no con todo esto, tus reflexiones sobre este tema son importantes y orientan la conversación sobre lo que es Agile y lo que no.

Este texto proviene del Blog de SPaMCAST y fue traducido al alemán por nosotros.