in Uncategorized

Teoría de las restricciones ágiles de Evan

¡Una organización solo puede ser tan ágil como la menos ágil de sus divisiones!

Por: Evan Laybourn

Traducido y adaptado por: Jorge Valdés Garciatorres.

Cuando se trata de explicar por qué la agilidad de negocios es importante, y con mis disculpas y extrapolando el planteamiento de Eliyahu Goldratt, a menudo hablo sobre la “Teoría de las restricciones ágiles de Evan”.

“¡Una organización solo puede ser tan ágil como la menos ágil de sus divisiones o áreas!”

Básicamente, la teoría de las restricciones establece que existe un factor de restricción en cualquier proceso. Más importante aún, que siempre habrá un factor restrictivo. La teoría de las restricciones ágiles es que, en una organización, siempre habrá una restricción para la agilidad de negocios. Hace 20 años, eso era todo. Ese era tu equipo de software. Y es por eso que era lógico que Ágil, con “A” mayúscula Ágil, emergiera en ese dominio. Hoy en día, la restricción de la agilidad no está dada por el desarrollo de aplicaciones, sino por el área de recursos humanos, finanzas, la PMO  o el departamento legal.

Puede ayudar pensar en el trabajo que se lleva a cabo en una organización como un flujo. Tomemos una organización que desarrolla software. Por un lado, tenemos los requerimientos del  usuario o negocio  y por otro,  el entorno de producción. En algún lugar a lo largo de este flujo está la restricción limitante. Tal vez a nuestros desarrolladores les lleve demasiado tiempo entregar productos. Así que introducimos, por ejemplo SCRUM.

Eso amplia el flujo en nuestros equipos de desarrollo. ¡Genial!. Excepto que SCRUM  no ha sido tan efectivo como esperábamos. Todavía está tomando demasiado tiempo entregar las soluciones. El hecho triste es que muchas organizaciones se detienen aquí y dicen “bueno, el enfoque o filosofía Ágil no funcionó”, y no analizan donde se generó la siguiente restricción en el sistema. Tal vez ahora sea el despliegue de las soluciones el cuello de botella. Así que vamos a traer DevOps. ¡Genial! – eso amplia la capacidad del flujo.

Estos no son problemas fáciles de resolver. No es solo una cuestión de pedir a Finanzas y Recursos Humanos que adopten Scrum o Kanban (no creo que eso haya funcionado, incluso para los equipos de software). Estos equipos pueden introducir importantes barreras culturales y de experiencia. Estos son equipos que miran sus formas actuales de trabajar y dicen; “Siempre hemos trabajado de esta manera”. Y en muchos casos con bastante éxito. Por lo tanto, si queremos introducir agilidad en estas divisiones, debemos comunicar que no se trata de solucionar un problema. Estamos cambiando fundamentalmente la forma en que la organización, como un todo, opera en el mercado. En otras palabras, estamos mejorando los resultados para toda la organización, no solo una sola división.

Pero ahora habrá una nueva restricción. Por lo tanto, necesitamos una visión más amplia. Tenemos que tener un enfoque de agilidad de negocios. ¿Dónde está la próxima restricción? Tal vez sea Finanzas, nuestro proceso de elaborar presupuestos. Tenemos un proceso de presupuesto de 18 meses que limita un ciclo de desarrollo para el que ahora tenemos la capacidad de desplegar diariamente. Es momento de arreglar esta nueva restricción y después evaluar donde surge la siguiente restricción, quizás sea en RH o en  la PMO.

En la economía actual, estas son las áreas que restringen la agilidad de una organización. En muchos sentidos, esta es la definición de agilidad de negocios. Tomar la mentalidad de agilidad y la práctica de Agile, y aplicarla en toda la organización. Pero va más allá de eso también. Entra en la propia cultura y estructura de la organización. ¿Está la organización diseñada para ser competitiva en un mercado ambiguo e impredecible?

El punto es que siempre hay una restricción en la agilidad de su organización que, a su vez, limita su capacidad para adaptarse a un mercado impredecible y ambiguo.

Entonces, si siempre hay una limitación de lo ágil que puede ser, ¿dónde está esta limitante en su organización? ¿Es en el área de infraestructura de TI  o  en el área de desarrollo de software? Puede que no estés desplegando la Agilidad con “A” mayúscula  a la perfección, pero ¿Estás trabajando realmente en el factor limitante para la agilidad de negocios? Déjame saber que opinas.