¿Cómo puede ayudar Scrum a una compañía tradicional que no quiere cambiar su cultura?

Las puertas representan decisiones, si no abrimos ninguna
seguiremos inmersos en la incertidumbre - cortesía de Pixabay

Tuve una interesante conversación con mi compañero José; me dijo que en los productos y proyectos de las grandes compañías no hay tanta incertidumbre como podamos creer, más bien las grandes compañías crean su propia incertidumbre... Con esta frase todos mis sentidos se agudizaron, en mi interior, eso tenia sentido y nos sumergimos explorando esa posibilidad de incertidumbre inducida.

Las principales causas que crean incertidumbre en una compañía con un mando y control inflexible suelen ser:

• El miedo a fallar es algo corriente en este tipo de compañías, y como nadie quiere fallar por las penalizaciones que pueda haber, resulta que los mandos intermedios no quieren tomar decisiones hasta que a posteriori ya haya tienen riesgo. Se escaquean y le pasan la patata caliente al proveedor, de ahí que proliferen los proyectos cerrados en los que todo el riesgo lo asume el proveedor. Un proyecto liderado por un proveedor implica una toma de decisiones por parte de un jefe de proyecto que no están alineadas con el negocio, y por tanto ajenas a las necesidades reales de los usuarios. Y ya tenemos un primer grado de incertidumbre que se refuerza con la incertidumbre que genera el cliente, que para diluir la responsabilidad muestra el producto en forma de demos a gestores de TI, responsables de negocio y usuarios clave. La solución da vueltas por la compañía, y si no ha armado ningún revuelo significativo se acepta de forma tácita. Por supuesto esto lleva irremediablemente a productos mediocres.

• Otro factor importante en la creación de incertidumbre es la no retención del conocimiento. Con cada nuevo proyecto licitian al menos tres proveedores, y si la compañía elige el más barato probablemente vendrá un equipo del proveedor que desconozca el producto y se meta de lleno en un código que desconoce y del que la documentación es insuficiente. Aunque se eligiera al mismo proveedor probablemente las personas del equipo no serian las mismas, porque en el tiempo entre proyectos el proveedor las habrá recolocado en otros proyectos. Personas ignorantes de la situación real del software se harán cargo del proyecto, ocultarán su ignorancia, y como se suele decir la ignorancia es valiente, así que se acaba inyectando incertidumbre a marchas forzadas.

• La contratación también ayuda a crear incertidumbre; ninguna de ambas partes firmará el contrato hasta que esté convencida de que cuando se tuerzan las cosas podrá echarle la culpa a la otra parte, por tanto cuando haya problemas habrá una dura negociación alrededor las ambigüedades, asunciones y malentendidos del alcance inicial. Finalmente el cliente acabe asumiendo parte de estas como mal menor y la calidad del producto se verá seriamente afectada.

• Cuando los intereses y objetivos de los involucrados no están alineados se produce una colaboración muy débil y ocurren situaciones imprevisibles que no sabes qué ha pasado y el proyecto toma una dirección divergente al sentido común. En este sentido los inyectores de incertidumbre más potentes son los bonus, incentivos y variables.

Scrum es un marco de aprendizaje sobre producto y proceso que a través de sus ciclos cortos lidia muy bien con la incertidumbre, y también puede lidiar con la incertidumbre inducida. Ante la carencia en la toma de decisiones, Scrum proporciona con sus ciclos cortos muchos momentos en los que los incrementos pueden rebotar en la compañía, a veces se aceptarán de forma tácita, otras se descartarán, pero de forma temprana. Ciclos cortos aceleran el aprendizaje, con lo que el conocimiento perdido se recreará antes. Ciclos cortos traen rápidamente a la luz ambigüedades, asunciones y malentendidos, con lo que sus efectos son mitigados y hasta eliminados rápidamente, y los incrementos crearán confianza, que aunque solo fuera débil, mejorará la colaboración. De la misma manera la divergencia en los intereses y objetivos tendrá efectos tempranos y el sistema aprenderá de forma temprana a lidiar con los mismos.

Todo esto tendría sentido si la compañía permitiera una verdadera aplicación de Scrum, sospechamos que la realidad sería muy distinta, el intento acabaría en la aplicación de un ScrumBut adaptado que haya absorbido las disfunciones y problemas sistémicos, y finalmente estresaría la compañía hasta limites insospechados y se llegaría a la conclusión de que Scrum no es para la compañía.

Mis agradecimientos a José Moro, realmente disfrutamos con mucho humor de la conversación y las especulaciones... son años de experiencias y vivencias que nos muestran que el post no va tan desencaminado :-P