Estructura del Libro

Advertimos que este documento puede causar reacciones indeseadas en el lector. Una de ellas, es que al leerlo se piense que estamos hablando de Ciencia-Ficción. ¿Empresas sin estructuras jerárquicas claras que garanticen el alineamiento? ¡Una locura!

Si hacemos esta advertencia es porque están a punto de cumplirse veinte años desde que unos señores propusieran llamar “Agile” a las metodologías de desarrollo de software que rompían con todo lo establecido desde los comienzos de la informática. Hace veinte años, el Manifiesto Agile para el Desarrollo de Software también parecía una auténtica locura, si bien ahora no se concibe otra forma de desarrollar software moderno.

NOTA: si como lector no compartes la idea de que las Metodologías Agile son la forma idónea de acometer nuevos desarrollos de productos de software, quizás este libro no va a ser de tu agrado. La aceptación del cambio (si es para bien) sobre el plan establecido es un valor requerido para poder asimilar lo que vamos a exponer.

Otra reacción indeseada puede tener lugar leyendo la primera parte del libro, pudiéndose pensar que es un resumen de teorías y modelos ya establecidos y bien reconocidos. Incluso, los lectores del libro Management 3.0, de Jurgen Appelo, podrían pensar que es una especie de réplica. En primer lugar, recomendamos la lectura del libro de Appelo, si bien no es requerida para entender lo aquí expuesto, pero avisamos desde el comienzo que nuestra propuesta va mucho más allá de la recogida en Management 3.0 para formar líderes Agile. Si repasamos y resumimos en la primera parte estos campos teóricos, también recogidos y descritos por Appelo, es porque, al igual que él, pensamos que son necesarios para entender la viabilidad de nuestra propuesta. Durante ese repaso a las teorías existentes ya demostradas, vamos a ir exponiendo su aplicación para resolver los problemas a los que la empresa jerárquica, o empresa eficiente, se enfrenta.

Una vez expuesto este descargo de responsabilidad, hemos de decir que a lo largo de nuestra trayectoria profesional hemos experimentado emoción y fantasía siempre que nos hemos incorporado a un nuevo proyecto. Sin embargo, aunque por lo general estas sensaciones han sido independientes del tamaño de las compañías en las que hemos trabajado, si la empresa en cuestión era grande, además hemos sufrido una gran tensión, como si cualquier fallo pudiera ser fatal debido a la envergadura de la compañía.

Evidentemente hablamos de nuestra experiencia personal, que no tiene por qué coincidir con la tuya, pero pensamos que puede resultar muy enriquecedora. En ocasiones algunos de nosotros nos hemos cuestionado el porqué de esa diferencia emocional, estando en ambos casos igualmente comprometidos con los proyectos, e igualmente expuestos en caso de fracaso.

Como es natural, una vez adaptados al cambio todos coincidimos en que el estado de nuestra motivación personal y de nuestro bienestar en cada situación dependía de las personas con las que nos relacionábamos, ya fueran jefes, compañeros o empleados, así como del grado de éxito alcanzado por la iniciativa, más que del tamaño o las características de la empresa en la que se desarrollaba el proyecto.

Sin embargo, mientras buscábamos las claves para poder aplicar la filosofía Agile con éxito en las grandes empresas, pudimos constatar algo intuitivo en lo que probablemente estarás de acuerdo con nosotros: el ambiente de trabajo y las relaciones entre las personas coinciden en gran medida con la cultura y con la filosofía de trabajo general en cada empresa, características ambientales que al final repercuten directamente en la motivación del individuo. Esta es la razón por la que nosotros consideramos al individuo como parte fundamental de la organización, y lo situamos en el centro de nuestro modelo en agilecorporation.org.

Nuestra intención es que, como responsable de tu ámbito de actuación e independientemente de su tamaño, y cómo individuo que busca mejorar de forma continua, encuentres aquí las claves para establecer mecanismos que mejoren la productividad y la eficacia, tanto de tu trabajo como del de tu equipo. Al hilo de esto, una alumna nuestra nos comentó una vez que, según su experiencia, trabajar en modo Agile es ser feliz en el trabajo y pensamos que no andaba mal encaminada.

Este libro ha sido desarrollado por una célula de trabajo de agilecorporation.com, autodenominada The Jets. En el momento de la primera edición la célula cuenta sólo con tres miembros, que pretenden dotar a los gestores de un manual de lectura amena que sirva como guía de referencia a nuestro modelo, y que sea una fuente de ideas que te anime a abrazar sin complejos ni dudas la filosofía de trabajo Agile.

Ya en términos prácticos, el objetivo técnico es presentar y desarrollar lo que hemos denominado “Marco de Trabajo Agile Corporation” (Agile Corporation Framework, o ACF). Este marco define una forma inteligente y ordenada de aplicar la Filosofía Agile a corporaciones, de forma distinta pero compatible con las metodologías existentes para la extensión masiva de dicha filosofía a grandes empresas. Para ello, se nutre de otras valiosas teorías precedentes como Complexity Theory y Self Determination Theory, utilizándolas como pilares del modelo, para después desarrollarlo fundamentalmente con base en la experiencia real de los autores del libro, fundadores asimismo de agilecorporation.org.

La información se estructura de la forma siguiente:

• En el primer capítulo se consignan las Bases del Modelo a exponer, es decir, la Filosofía Agile.

• En el segundo capítulo se efectúa una introducción al modelo Agile Corporation Framework (ACF).

• En los capítulos tercero y cuarto se resumen las conclusiones obtenidas de las teorías SDT (Self Determination Theory) y CT (Complexity Theory) que sostienen nuestro Marco de Trabajo de Agile Corporation.

• En los capítulos posteriores se revisan los conceptos derivados del Manifiesto Agile, en los cuales se inspira Agile Corporation, para pasar al análisis del ACF, sus dimensiones y sus partes.

• Para evitar que este modelo quede como algo idílico pero utópico, durante su descripción también se explica cómo implantarlo teniendo en cuenta su capacidad de aplicación parcial en una organización, lo cual posibilita su implantación progresiva y sin riesgos. Para ello se explica cómo conviven ambos modelos, es decir, cómo interactúan las partes que están dentro de la Zona del Ecosistema Agile (AEZ) con las partes del exterior, pertenecientes al modelo clásico de empresa eficiente. Para ello, al final de cada uno de los capítulos de descripción del modelo, figura una sección donde se explica cómo conviven los elementos específicos de dicho capítulo con la parte de la empresa que sigue siendo jerárquica.

• En el último capítulo se trata específicamente la implantación del modelo y, en concreto, se muestra cómo arrancar la Zona del Ecosistema Agile (AEZ), esto es, cómo dar el primer paso y a partir de ahí cómo hacer crecer y desarrollar este germen Agile.

1 Las Bases del Modelo

“Nothing is particularly hard if you divide it into small jobs”

(“Nada es especialmente difícil si lo divides en pequeños trabajos”)

Henry Ford

1.1 El Origen y el Reto

La forma tradicional de resolver un problema complejo o de efectuar un trabajo de gran envergadura siempre ha supuesto su división en partes más pequeñas y manejables, para después abordarlas de forma unitaria y en un orden determinado. El conjunto de dichas partes, el faseado de las mismas, el arbitraje de su secuencia y los tratamientos a efectuar en caso de error constituyen lo que se denomina un Proceso.

Un proceso parte de unas premisas o requisitos previos, precisa de una ejecución programada de tareas, admite paralelización de algunas fases, puede contener caminos críticos, e incluso puede registrar bloqueos entre tareas que tengan precedencia entre ellas, pero todos los procesos clásicos se caracterizan por su similitud con una cadena y sus eslabones. Cada eslabón produce resultados imprescindibles para el siguiente o los siguientes y normalmente no admite refinamientos, pues el control de calidad indica si sus resultados son suficientemente válidos o si se descartan por no alcanzar unos mínimos estándares de calidad.

Las empresas clásicas funcionan de esta forma, esto es, organizando todos sus procedimientos en forma de cadenas, en las que cada uno de los eslabones efectúa entregas formales al siguiente eslabón, con base en requisitos pactados y KPIs predefinidos. Este modelo ha aplicado históricamente tanto al Desarrollo SW como al resto de procesos de una empresa desde su establecimiento por Henry Ford en 1908, paralelizando algunas fases de la cadena, pero organizando el trabajo generalmente de forma representable con un Diagrama de Gantt.

A este modelo de empresa lo denominamos Empresa Eficiente o Empresa Competente (Proficient Corporation), que en cualquier caso es una empresa jerárquica.

Hasta el momento, dichas empresas eficientes han conseguido mantener su dominio gracias a planificaciones estratégicas adecuadas, procesos de control eficaces y sinergias corporativas. Estas prácticas y herramientas les han proporcionado eficacia suficiente en el contexto empresarial clásico, pues:

• Consiguen tomar decisiones corporativas con base en la inteligencia del negocio, con KPIs consolidados sobre cumplimiento de objetivos estratégicos.

• Reducen la volatilidad evitando errores y pérdidas con la obtención de sinergias, gracias a departamentos de compras, políticas de RRHH globales, o áreas de sistemas centrales especializados.

• Abordan grandes retos con proyectos muy complejos con cientos o miles de individuos implicados, todo bajo la perfecta coordinación de planes por parte de una oficina de proyecto especializada y transversal.

• Facilitan el dinamismo mediante contratos rigurosos con proveedores para la externalización de aquellos procesos que no se consideran core de la compañía.

• Se centran en el cliente alineando todas las capacidades transversales para que cada una de ellas aporte su mejor criterio al producto o servicio.

Esta gran orquestación no sería posible sin mediciones de todo tipo de parámetros, sin planificación de objetivos, o sin responsables de su cumplimiento, es decir, sin personas a quienes se pueda felicitar o amonestar por los resultados, que tomarán las decisiones importantes con base en la información consolidada y los planes acordados.

En cualquier caso, esta forma de proceder de la empresa eficiente hace ya mucho tiempo que dejó de ser efectiva en el nuevo contexto empresarial, que se caracteriza por lo siguiente:

• Es un entorno muy dinámico. Los ciclos de vida de los productos y servicios son cada vez más cortos, puesto que tanto los fulgurantes avances tecnológicos como la feroz competencia provocan que la rotación de los catálogos comerciales sea constante y además muy rápida.

• Las expectativas de los usuarios son cambiantes y crecientes. El usuario actual es un adicto a la tecnología y además cabalga a lomos de la tan traída y llevada Transformación Digital, por lo que cualquier idea nueva, aún sin madurar, que le permita distinguirse de la competencia se incorpora inmediatamente a la siguiente versión del producto.

Ambas características hacen que sea un reto estar a la altura de las circunstancias y mantener el tipo en la carrera comercial y empresarial. Para ello se necesitan nuevas herramientas, como veremos a continuación.

Una empresa eficiente aplica la estrategia clásica de liderazgo, basada en las Cuatro Virtudes Cardinales descritas por Platón en su obra “La República”:

• Identificando con prudencia las nuevas opciones para la obtención de ventajas competitivas.

• Analizando con templanza dichas opciones, para descartar las falsas oportunidades y las modas pasajeras, y validando sus ventajas.

• Abordando con fortaleza su aplicación bajo grandes planes bien dotados.

• Motivando con justicia a los responsables con premio o castigo según su desempeño.

Sin embargo, el entorno empresarial se está complicando de forma acelerada. Las disrupciones tecnológicas están siendo aprovechadas por nuevos actores que alteran continuamente las necesidades y las expectativas del fiel cliente de la empresa eficiente.

Tras las tres disrupciones tecnológicas acaecidas entre los siglos XVIII, XIX y XX, estamos viviendo la cuarta disrupción, también denominada “Industria 4.0”.

La “Industria 4.0”, llamada asimismo “Cuarta Revolución Industrial”, consiste realmente en el establecimiento de un nuevo paradigma industrial de organización, basado en la utilización simultánea de los últimos avances tecnológicos en las TIC, vinculados a Internet. La conjunción de Sistemas Ciberfísicos, Computación en la Nube, Ciencia de Datos, Inteligencia Artificial, M2M, auto-configuración, auto-optimización, aprendizaje automático, etc., ha dado lugar a un nuevo modelo de Factoría Virtual que replica la factoría real con objeto de medirla y controlarla, para obtener los mejores resultados posibles en la Cadena de Valor, haciéndola más flexible y colaborativa.

Pero no se trata exclusivamente de optimizar la producción industrial sacando el máximo jugo a las tecnologías disponibles para lograr producir con mayor calidad, mayor rapidez y menor coste, pues esta nueva revolución también tiene que ver con una respuesta organizada a las nuevas expectativas de los clientes, que cada vez demandan menos productos generalistas y más productos a medida, cuya personalización sería muy costosa o directamente inviable con el modelo tradicional de producción.

“Industria 4.0” es una denominación originalmente alemana (Salón de la Tecnología Industrial de Hannover, 2011: Plan de Acción de Estrategia de Alta Tecnología), universalmente aceptada en la actualidad (Programa H2020 de la Unión Europea), sin embargo, ¿se trata sólo de una nueva revolución industrial?

Está claro que no. A lo largo de la Historia, la industria ha ido incorporando nuevos ingredientes que han contribuido a la elaboración del gran pastel que ahora está en el horno, al que se puede considerar sin matices como la revolución industrial definitiva.

Las Revoluciones Industriales a lo largo de la Historia

Lo primero que llegó de forma impactante a las fábricas del siglo XVIII fue la sustitución progresiva de la fuerza animal, humana o natural renovable (molinos de viento, norias, etc.) por la fuerza mecánica del vapor de agua. Aunque la fuerza motriz del vapor se conocía desde la época de la Grecia Clásica (Aelópilo de Herón de Alejandría, Siglo I a. C.), hasta que James Watt inventó la máquina de vapor no se le dio al descubrimiento una aplicación práctica y útil en la industria.

Esta invención, junto con los yacimientos de hierro y carbón existentes en Inglaterra, dio lugar a la primera gran revolución industrial de la Historia, en el siglo XVIII.

La segunda revolución industrial llegó a principios del siglo XX, cuando el industrial norteamericano Henry Ford organizó en cadena la producción de sus fábricas, aplicando sistemáticamente las teorías de Taylor y logrando un aumento de eficiencia desconocido hasta el momento, junto con una racionalización rompedora del trabajo humano. En esta época, también hubo un factor adicional de importancia capital: se incorporaron la electricidad y el motor eléctrico (patentado por Nikola Tesla en 1887) a las fábricas, reduciendo o eliminando la dependencia del carbón, hecho que imprimió otro ritmo completamente distinto a la producción fabril de la época.

La tercera revolución industrial tuvo lugar a partir de mediados del siglo XX, con la incorporación a las fábricas de la electrónica, la informática, los automatismos, la robótica, los sensores, etc. A partir de este punto, las máquinas empezaron a asumir las tareas más pesadas y repetitivas, con lo que el ser humano se empezó a dedicar a las labores de control, calidad, puesta a punto de nuevos procesos, mantenimiento, reparación y, sobre todo, planificación fabril y programación de la robótica para cumplir con dicha planificación.

Y parecía que aquí se había terminado todo, pues ya sólo se esperaban mejoras en la robótica, en la electrónica, en las fuentes de energía alternativas, etc., pero una cuarta revolución industrial estaba aún por llegar, y vendría de la mano de la integración de nuevas tecnologías como la Inteligencia Artificial, la Ciencia de los Datos y, por supuesto, Internet. Se trata de los Sistemas Ciber-Físicos, que aúnan todas las tecnologías anteriores y que constituyen uno de los factores clave de la llamada Transformación Digital.

Debido a esta última disrupción tecnológica, continuamente surgen amenazas competitivas que provienen de empresas más ágiles y dinámicas, normalmente grandes empresas tecnológicas que diversifican su ámbito de actuación, o bien, startups liberadas de toda carga corporativa que surgen con ideas simples, casi siempre apoyadas en las nuevas soluciones tecnológicas.

La empresa eficiente se encuentra descolocada en este contexto. Sus procesos probablemente están optimizados mediante Lean Manufacturing con una eficiencia 6-Sigma (tasa del 99.99966%, esto es, 3,4 defectos por millón), sus cadenas logísticas están ajustadas al milímetro, y sus suministradores han sido seleccionados para brindar la mejor relación calidad/precio posible. Y, aun así, sus responsables contemplan desalentados cómo estas pequeñas empresas de plantillas quasi-universitarias les adelantan por la izquierda y por la derecha, o bien, cómo gigantes tecnológicos con presupuestos astronómicos les aplastan en la carrera competitiva.

El problema es que la inercia del mercado prácticamente ha desaparecido en la actualidad. Los clientes demandan productos y servicios con una velocidad e intensidad que no permite recorrer con eficiencia los diferentes estadios del modelo clásico de procesos, por lo que urge la instauración de un nuevo modelo para permanecer en ruta.

Para entender mejor el fenómeno que se está produciendo en el contexto empresarial utilizaremos un símil físico fácil de visualizar. Pensemos qué ocurriría en el mundo de la automoción si de repente desapareciera el rozamiento, o bien, si se redujera muchísimo. Bien es cierto que los grandes camiones optimizados para enormes cargas y rutas interminables se desplazarían a gran velocidad con un reducido consumo energético, con bajo desgaste de motor y con un impacto prácticamente nulo en sus neumáticos. Todo iría bien en las rectas, pero como contrapartida, en las curvas estos vehículos se saldrían siempre de la carretera. Sus sistemas de control de trayectoria clásicos tampoco serían eficientes en este nuevo entorno, en el que arrasarían los aerodeslizadores, vehículos muy ágiles y maniobrables ya preparados en la actualidad para circular sobre superficies de rozamiento bajo o variable.

La clave sería pues, trabajar para convertir los camiones en hovercrafts, vehículos de reacciones fulminantes, acordes con el nuevo firme de bajo rozamiento y también con las demandas de sus nerviosos y exigentes pasajeros, los clientes finales.

1.2 El Problema – Diversidad y Velocidad del Cambio

La empresa eficiente, como es esperado, aplica primero aquellos principios aprendidos que la hicieron fuerte. Ya en el pasado tuvo que afrontar grandes retos y siempre salió airosa. Su supervivencia hasta ahora es una prueba de su éxito, en su contexto convencional.

Pero esta vez la aplicación de los métodos de siempre no funciona, porque en este caso el reto no consiste en enfrentarse a una nueva disrupción tecnológica o a un reposicionamiento, sino que el nuevo desafío es un cambio radical de las reglas del juego. Y para este nuevo juego se necesitarán nuevos métodos, se necesitará adaptación. Veamos unos ejemplos para clarificar el horizonte actual.

Las redes locales aparecieron en los años 70, pero tuvieron su auge veinte años después. Esta tecnología fue determinante en muchos aspectos, sobre todo en lo relativo a eficiencias internas y a la libertad para organizarnos de una forma distinta. Pensemos en que la verdadera razón para instalar redes locales en las empresas era la de sacar provecho a los puestos de trabajo inteligentes. Empezaban a verse los ordenadores personales, pero sólo como islas usadas por los contables o por los directivos para sus hojas de cálculo y sus informes, los cuales se compartían a través de disquetes. La instalación de una red local no sólo permitiría potenciar dichos ordenadores, sino democratizarlos dentro de la oficina dando más poder al resto de los empleados, que podrían seguir accediendo al ordenador central, situado en el centro de procesos de datos de la empresa, mediante el propio PC en lugar del terminal tonto al que éste reemplazaba.

Dos tecnologías, muy diferentes en su concepción, prometían todo en aquella época: Token Ring y Ethernet. Hoy sabemos cuál fue la opción vencedora, pero en aquellos días la cuestión representaba una decisión importante y difícil. Lo bueno es que tuvimos 20 años para decidir si las redes locales nos eran de ayuda y qué tecnología tenía el futuro asegurado.

Hablemos ahora sobre Internet. Aunque parezca asombroso, surgió en 1969, pero no tuvo presencia comercial efectiva hasta principios de los 90. Desde ese momento, aún tuvieron que pasar 10 años hasta que supusiera una disrupción a nivel global, y 10 años más para que se produjera el boom .com, abriendo completamente un nuevo canal. Por lo tanto, hablamos de que los directivos de las empresas eficientes de aquellos años tuvieron 10 años para entender qué podía aportar Internet a sus negocios y de qué forma se podía crear un portal web para sus empresas.

Eso nos lleva a otra disrupción tecnológica importante del pasado, la de los smartphones. Aparecieron en torno al año 2000 con los legendarios Nokia Communicators, pero hasta la comercialización del iPhone en 2007 no cambiaron realmente los hábitos de las personas ni se dio a los terminales el uso actual, en el que se los utiliza para casi todo y ya prácticamente no se usan para hablar. Pero volviendo al mensaje que queremos expresar, el hecho es que en este caso los directivos de la empresa eficiente también pudieron analizar las oportunidades y las alternativas tecnológicas de los smartphones durante años antes de empezar a planificar el desarrollo de Apps en sus empresas.

Por tanto, la cuestión no es la materialización de estas disrupciones tecnológicas, pues siempre las ha habido y además de mucho rango. Lo que está cambiando es la velocidad con que aparecen y el tiempo que la empresa eficiente tiene para analizarlas e implantarlas. Tomando las cifras temporales de los ejemplos anteriores, las conclusiones son claras:

• Empleamos 20 años para elegir si debíamos usar Ethernet o Token-Ring como tecnología de red local.

• Empleamos 10 años para decidirnos a publicar nuestras webs.

• Empleamos 7 años para percibir la potencialidad de un invento como el Smartphone y desarrollar nuestras Apps asociadas al mismo.

Hoy en día casi no tenemos tiempo para pensar qué debemos implementar o qué solución debemos utilizar para resolver un problema, tomando ideas y tecnologías del gran caldero en ebullición que es la transformación digital. Cada día nacen y mueren Apps de funcionalidad prodigiosa cuyos ciclos de vida se solapan, si no se superponen. Cada día se toman decisiones de implementar un producto, y si no se hace rápidamente éste puede ser arrollado por una miríada de productos similares de la competencia.

Así pues, hay una diferencia fundamental entre las tres primeras Revoluciones Industriales ya acaecidas y la cuarta que estamos viviendo, que es la velocidad del cambio. La dificultad no sólo reside en cómo acometer las oportunidades y/o amenazas que surgen, sino que también está en la propia complejidad intrínseca de cualquier corporación para adaptarse con dinamismo a los cambios que ello conlleva, debido a su rigidez endémica. Esa es la verdadera desventaja de la empresa eficiente con respecto a las startups.

Ahora surgen nuevas exigencias para la empresa eficiente:

• Se exige que la empresa tome cientos de decisiones con base en oportunidades y/o amenazas particulares y que lo haga rápidamente, en lugar de tomar decisiones globales bien planificadas.

• Se necesitan soluciones rápidas, frescas y ad hoc, en lugar de soluciones homologadas bien integradas.

• Se precisa más trabajo conceptual y creativo que nunca, con capacidades especiales y diversas que no encajan bien con los procesos tradicionales de RRHH.

• Se busca una cultura de trabajo en grupo, con equipos dinámicos, multidisciplinares y autónomos, y con líderes serviles, en lugar de disponer de responsables que carguen sobre sus hombros el peso de las grandes decisiones.

• Se necesita adaptación de forma continua a un entorno en intensa rotación, en lugar de aferrarse a planes estratégicos a medio y largo plazo.

Urge adoptar una nueva filosofía que permita agilizar los procesos empresariales, habilitándolos para responder con rapidez tanto a los súbitos cambios de requerimientos de usuario, como a los cambios en los suministradores y en las tecnologías, permitiendo efectuar entregas incrementales de valor con celeridad suficiente.

Un análisis incorrecto o poco profundo de la situación puede llevar a pensar que se está trabajando de forma acorde con este nuevo entorno hiperdinámico que nos ha tocado vivir en el siglo XXI. Como consecuencia de ello se puede llegar a situaciones bloqueadas por la autocomplacencia, al percibir realidades adulteradas o espejismos como los que exponemos a continuación.

La idea de fondo es que la adaptación de las empresas al nuevo medio ambiente se ha de orquestar adecuadamente. La aplicación de soluciones de renombre o de moda de forma súbita e irreflexiva suele ser contraproducente.

Primer espejismo: “Creer estar centrado en el cliente”

Las empresas eficientes afirman estar centradas en el cliente, lo cual resulta imposible en la actualidad sin abandonar los modelos empresariales jerárquicos, caducos y secuenciales, cuya tremenda inercia hace inviable seguir el paso que marca el mercado, que ha deificado al cliente y está atento a todos sus requerimientos de forma instantánea.

Lejos queda ya la época en la que el cliente visitaba una tienda y tenía que elegir entre las dos o tres soluciones disponibles, seleccionando la que mejor se adaptara a sus requisitos. En este ambiente, una empresa jerárquica será vapuleada constantemente, pues mientras intenta adaptar sus cadenas productivas a nuevos escenarios de requerimientos, el cliente seguirá en movimiento, cambiándolos en vivo.

La solución, por tanto, comporta adaptarse al nuevo esquema abandonando el antiguo. Esto requiere la adopción de un modelo empírico que revise los requisitos constantemente y de forma ágil, y que oriente la empresa a la organización por productos, no por familias, ni por tecnologías, ni por generaciones, ni por series.

Segundo espejismo: “La solución es comprar una Startup”

Las grandes corporaciones ya hace tiempo que han comprobado que adquirir y absorber la startup de turno no es una opción válida, pues tan pronto como ésta es sometida a su modelo tradicional de empresa eficiente, forzándola a integrarse en concienzudos procesos corporativos, la idea fresca se vuelve rancia y la creatividad de los recursos de la startup se diluye como un azucarillo en el océano, o como lágrimas en la lluvia, parafraseando al replicante Roy Batty en su entrañable óbito.

Tercer espejismo: “Hay que construir un gran plan de transformación”

La primera decisión estratégica global suele consistir en ordenar la aplicación inmediata de Metodologías Ágiles y proyectos basados en tecnologías disruptivas, buscando un problema que resolver para cada solución tecnológica. Esta táctica suele dar lugar al lanzamiento de grandes Planes de Transformación.

Estos planes de transformación suelen estar basados en la adopción masiva y no orquestada de Metodologías Ágiles, combinada con la implantación de nuevos procedimientos tecnológicos y normalmente desacoplada de la facción metodológica. Aunque se abordan con gran optimismo y presupuesto, suelen fracasar y sólo quedan de ellos ciertas reminiscencias en algunos departamentos entusiastas.

Cuarto espejismo: “La solución es crear equipos Agile aislados”

Otra decisión incorrecta deriva de la aplicación apresurada de Agile por tratarse de algo de moda, sin orquestar un plan de implantación y despliegue adecuado acorde con la nueva filosofía, que suele traducirse en la creación de Equipos Agile en un entorno hostil.

Los Equipos Ágiles surgen y crecen con problemas en un entorno plagado de enemigos, que en realidad no piensan en adaptarse al nuevo medio bajo ningún concepto, y los proyectos terminan como simples ejercicios prácticos para cumplir objetivos y asegurar el cobro de incentivos, aportando apenas valor al cliente final. Y no es que no se tenga éxito en la adopción de la nueva filosofía, pues se logra montar equipos Agile, pero chocan frontalmente con un modelo jerarquizado que les arrebata su autonomía, factor que resulta clave en la filosofía Agile, abocándolos al fracaso desde el minuto cero.

Quinto espejismo: “Liberemos a los equipos de los servicios internos, de someterse a las sinergias de la corporación”

Otra decisión incorrecta es liberar a los Equipos Agile del cumplimiento de las políticas transversales ofrecidas por las áreas funcionales especializadas, desaprovechando eficiencias, lo cual presenta dos conflictos asociados al conocido modelo utópico de “un país, dos sistemas”:

• Las empresas tradicionales ofrecen más resistencia a rebajar los controles, adoptando soluciones sólo parciales y con nombres de moda (Squads, Tribes, Chapters, Guilds, etc.), pero las métricas modelan los comportamientos, y los controles y el sistema modelan la cultura, lo que representa otra desventaja de la corporación frente a las startups. Dejando a un lado la adquisición de la startup que la empresa considere su competencia natural (Espejismo 2), la otra alternativa es replicar su filosofía, política que también fracasa debido a la imposición de baterías de métricas, indicadores y pesados cuadros de mando que acaban por asfixiar y desanimar a los nuevos equipos, que finalmente vuelven a ser jerárquicos.

• Por otra parte, si se eliminaran las métricas globales y los controles, y si la única solución para la empresa eficiente fuera convertirse en la suma de varias o muchas pseudo startups con iniciativas Agile, este modelo tampoco tendría ninguna ventaja distintiva frente a las startups contra las que compite, puesto que en tales circunstancias lo único que le quedaría a la corporación serían las sinergias derivadas de sus servicios corporativos (factor que se puede aprovechar perfectamente para la Transformación Agile, como veremos más adelante en el capítulo de Carreteras Asfaltadas o Paved Roads).

Sexto espejismo: “La solución definitiva, que las iniciativas sean en sí mismas una startup”

Y finalmente, pero no menos incorrecta, está la iniciativa de lanzar ideas rompedoras o urgentes encapsulándolas en una startup propiedad de la corporación y con vida propia al margen de su empresa nodriza.

Esta estrategia suele tener éxito mientras la startup en cuestión sigue siendo independiente, pero experimenta mort subite al integrar la startup ya operativa en la empresa principal, repitiéndose el efecto del Espejismo 2 pero esta vez de forma endogámica, al ser la startup propiedad 100% de la empresa matriz.

1.3 ¡Eureka!

La herramienta que utilizaremos más adelante para identificar el problema de las empresas eficientes es la SDT (Self Determination Theory). Esta teoría nos abre los ojos a las necesidades esenciales para la motivación intrínseca, es decir, nos indica cómo motivar a los individuos que forman parte de las organizaciones para que realicen un trabajo sin necesidad de estímulos externos tipo “Zanahoria”, como el dinero, los ascensos y otros beneficios, o tipo “Palo”, como castigos, penalizaciones, etc.

Obviamente, la motivación necesaria será suma de la intrínseca más la extrínseca, pero a más motivación intrínseca, serán necesarios menos palo y menos zanahoria. Es más, para trabajos de tipo conceptual y creativo, estas motivaciones coercitivas en ocasiones resultan contraproducentes, siendo necesario recurrir precisamente a la motivación intrínseca sobre la que arroja luz la SDT. Como adelanto de lo que veremos más específicamente en el capítulo 3 para Self Determination Theory, las conclusiones de Daniel Pink van precisamente en esta línea. Daniel Pink afirma en su libro “La sorprendente verdad sobre qué nos motiva” que trabajar es algo tan natural como jugar y descansar y que, bajo las condiciones adecuadas, el ser humano aceptará e incluso buscará este tipo de responsabilidad. Además, refuerza su argumento subrayando que la mayoría de las personas se mueven empujadas más por la motivación intrínseca que por la extrínseca, es decir, les importa más la satisfacción que les puede reportar un determinado trabajo que las recompensas externas que recibirán por realizarlo.

Pues bien, tras analizar en profundidad la filosofía Agile y sus metodologías derivadas, concluimos que Agile es sólo una demostración empírica de la veracidad y validez de la SDT, pues el factor común entre dichas metodologías es precisamente que cubren las necesidades esenciales de la motivación intrínseca:

• Autonomía. Nos gusta dirigir nuestro propio comportamiento nosotros mismos. En cualquier caso, autonomía no quiere decir independencia, sino poder elegir dentro de un marco de interdependencia.

• Maestría. Deseamos ser cada vez mejores en lo que nos importa. La búsqueda de la maestría nos ayuda a estar satisfechos con nuestro trabajo y nos empuja hacia un nivel superior de productividad.

• Vinculación. Necesitamos sentir que somos parte de un equipo, en el que desempeñamos un papel que es importante para los demás y que es también acorde con nuestras capacidades.

Continuando con la línea argumental, la clave es pues la necesidad de alineamiento de propósitos entre los equipos y la propiedad, lo cual da lugar en la actualidad a la necesidad de controles, jerarquías y sinergias en las corporaciones. Como contrapartida a estas características de la empresa eficiente veremos que, aunque la SDT es directamente compatible con las startups y con otras organizaciones pequeñas en las que la propiedad está muy próxima a las operaciones, no obstante, puede presentar problemas de alineamiento con las organizaciones más grandes si no se aplica adecuadamente. Tanto la Self Determination Theory como Agile son válidas en general por sí solas para organizaciones simples, pero necesitan orquestación adicional para su aplicación en organizaciones más complejas.

Nuestro modelo, al que hemos denominado Marco de Trabajo Agile Corporation (ACF, Agile Corporation Framework), surge tras el estudio y aplicación de los mecanismos contenidos en la Complexity Theory (ver capítulo 2) para compatibilizar Agile con las particularidades y características de las empresas complejas. Estos mecanismos facilitan la implantación global de Agile en dichas empresas garantizando las necesidades esenciales de motivación intrínseca junto con el control global y el aprovechamiento de sinergias corporativas.

Tal y como exponíamos en el apartado descriptivo de la estructura del libro, el objetivo de éste es presentar y desarrollar lo que hemos denominado “Marco de Trabajo Agile Corporation”, o Agile Corporation Framework (ACF), cuyo propósito es la aplicación de la Filosofía Agile a corporaciones, con base, entre otras cosas, en Complexity Theory, Self Determination Theory, y la experiencia práctica de los autores.

Como veíamos en los apartados anteriores, la empresa eficiente como tal no tiene cabida en el entorno actual. Sin embargo, posee activos que le proporcionarían ventajas competitivas frente a la startup de turno con la que compite, si consigue liberarse primero de sus estructuras y soluciones rígidas globales, que resultan incompatibles con la adopción ágil de múltiples decisiones concretas para crear soluciones ad hoc a problemas específicos. En cualquier caso, aunque dicha liberación ciertamente ha de ser disruptiva, no tiene por qué ser totalmente destructiva para la organización, esto es, la corporación actual tiene muchas ventajas competitivas que se pueden aprovechar integrándolas en la nueva filosofía de la agilidad, como es el caso de las Carreteras Asfaltadas (Paved Roads), como se verá en su momento en el apartado homónimo.

La situación global es compleja y el problema, visto desde la Dirección de la empresa, también es complejo.

Como estudiaremos más adelante y según se concluye en la Complexity Theory, la única forma de abordar problemas complejos es mediante organizaciones complejas efectivas, ya que la solución está precisamente en la descomposición del problema y en la delegación de decisiones a tomar en menor escala organizativa.

Una estructura jerárquica es un amplificador de decisiones simples, pero la solución en el entorno actual es otra. En capítulos posteriores expondremos que la solución supone crear un sistema adaptativo complejo, que no complicado, que adopte de forma dinámica decisiones parciales conforme surjan situaciones concretas. Este escenario es perfectamente compatible con el aprovechamiento de sinergias corporativas (también denominadas Carreteras Asfaltadas, Paved Roads) y con la gestión de riesgos (Gestión de Umbrales de Riesgo o Risk Threshold Management) que eviten que ciertas decisiones tomadas en un escenario local afecten a su entorno o a la globalidad.

Esta es la visión del Agile Corporation Framework, un modelo inspirado en el manifiesto Agile que pretende aportar soluciones a la empresa compleja y eficiente, con rentabilidad que defender, que desea sacar partido de sus sinergias corporativas y necesita gestionar el riesgo de sus iniciativas.

1.4 El porqué de la iniciativa

Scrum y los otros marcos metodológicos existentes son contextos de procesos que permiten abordar problemas complejos y dinámicos, liberando productos con el mayor valor posible. Scrum inspiró en su día la filosofía Agile y resulta óptimo para su uso en startups, pero su eficiencia disminuye cuando se aplica a empresas grandes debido a que está pensado para equipos de nueve individuos como máximo.

Para intentar aplicarlo a corporaciones evitando estos efectos indeseados, se han planteado modelos de escalado que lo utilizan como base pero que implementan una supraestructura adicional que permite alinear a los equipos Scrum que participan en el producto. Los casos más conocidos son los siguientes:

• LeSS, Large Scale Scrum, o Scrum a Gran Escala. LeSS es Scrum aplicado a muchos equipos que trabajan juntos en un solo producto, esto es, LeSS es realmente Scrum, no un Scrum nuevo y mejorado. LeSS trata de aplicar los principios, el propósito, los elementos y la elegancia de Scrum en un contexto a gran escala, de la manera más simple posible.

• SAFe, Scaled Agile Framework. SAFe parte de Scrum y establece un completo marco de trabajo que permite expandir Scrum para desarrollar soluciones o iniciativas a gran escala. El modelo permite varias configuraciones en función del tamaño de la organización o de las iniciativas en cuestión, adaptándose a las necesidades de negocio de cada organización. SAFe incluye los roles, responsabilidades, artefactos y actividades necesarias para implementar Lean-Agile a gran escala.

• Scrum de Scrums. Es una primera aproximación al escalado de Scrum, presentada por Jeff Sutherland en 2001. De forma análoga a LeSS, se trata de una técnica de escalado que se puede aplicar cuando varios equipos trabajan en un único producto o familia de productos, constituyendo en esencia un procedimiento basado en Scrum puro.

Como vemos, el problema de aplicación de la filosofía Agile a grandes empresas ya ha sido abordado, con bastante acierto hasta el momento, por los modelos de escalado de Metodología Scrum en el entorno del Desarrollo SW, sin embargo, estos modelos se centran en la proyección a escala de los valores y principios del Manifiesto Agile, logrando como veremos un éxito modesto al enfrentarse con situaciones de gran complejidad, como puede ser la de una corporación.

Agile Corporation Framework no es una metodología sino un marco organizativo de trabajo, que es abierto, pues permite acoger a los marcos metodológicos Agile mencionados (LeSS, SAFe y otros), y que permite también gestionar la empresa por parte de sus propietarios, tratándola como lo que realmente es: un sistema complejo adaptativo, como estudiaremos más adelante.

En general, las razones por las que no acaba de funcionar la filosofía del Manifiesto Agile en empresas complejas son las siguientes:

• Hay distancia entre la propiedad y los equipos Agile. En empresas pequeñas, el Propietario es el Director, y a veces también el Project Manager y el Project Leader. El control es total debido a la sinergia que se deriva del solapamiento de funciones, y está completamente sintonizado con los recursos disponibles y con los objetivos marcados. En las empresas complejas esta distancia suele ser muy grande.

• Los principios del Agile manifiesto menoscaban el aprovechamiento de sinergias corporativas. Las empresas complejas tienden a industrializar y burocratizar los servicios corporativos haciéndolos muy eficientes y representando una ventaja competitiva en sí mismos.

• Se hace difícil efectuar una gestión de riesgos en cuanto a los daños que un equipo Agile puede producir en los demás equipos. Las estructuras clásicas de las corporaciones implementan mecanismos de control de riesgo esenciales para evitar que un nuevo producto desestabilice al resto del catálogo. Agile rompe con todo y organiza la empresa de una forma distinta, sin tener siempre en cuenta dichos mecanismos de control, lo cual es especialmente importante durante la implantación, en la que las dos metodologías tienen que convivir durante un tiempo prolongado.

Al mismo tiempo, los modelos de escalado masivo tipo LeSS, SAFe, etc., intentan resolver el problema y son buenos como referencia, pero presentan a su vez problemáticas añadidas. Para empezar, podríamos decir que en general son “poco Agile”, como explicamos fácilmente a continuación: Imaginemos una empresa que quiere ser Agile. Si ordena a todos sus equipos implantar Scrum como modelo de trabajo, estaría incumpliendo el principio de autonomía de dichos equipos para organizarse de la forma que mejor vean, pues habrá equipos que, por sus circunstancias, funcionen mejor aplicando Kanban que Scrum.

Todos estos modelos Agile deben ser sólo eso, modelos de referencia para que los equipos alcancen antes la agilidad, pero no deberían ser impuestos en ningún caso. Dicho esto, se entenderán mejor las objeciones que indicamos a continuación sobre los modelos de escalado Scrum:

• Tienden a sobregestionar a nivel corporativo, como una forma de alineamiento y control del escenario resultante con equipos Agile. Tratan a las células Agile como electrones libres cuyo alineamiento debe ser asegurado mediante cadenas de ceremonias o estructuras de artefactos liderados de forma jerárquica.

• Implementan mecanismos de alineamiento y sincronización artificiales, que afectan al libre desempeño de las células, pues afectan negativamente a las necesidades esenciales de autonomía y competencia de sus integrantes.

• Aportan soluciones organizativas, como los chapters, que menoscaban el autogobierno de las células, pues establecen una organización matricial que interfiere con la auténtica filosofía Agile.

• Agrupan las células Agile mediante “tribus”, que realmente son un tipo de silo y que revierten la filosofía empresarial al implementar otra vez un modelo jerárquico de nuevo cuño.

En vista de todo lo anterior y pensando en empresas competentes, eficientes, con una rentabilidad que defender, y que necesiten la agilidad de una startup para sobrevivir en el contexto actual de mercado, desde agilecorporation.org proponemos un Framework Organizativo Agile a nivel corporativo.

Este Marco de Trabajo ofrece buenas prácticas también a las empresas pequeñas, no en vano está fundamentado en modelos metodológicos especializados en este tipo de empresas, no obstante, su aportación de valor aumenta en función del tamaño de la empresa, siendo diferencial en las grandes corporaciones.

A diferencia de otras iniciativas existentes en el mercado, el ACF (“Agile Corporation Framework”) proporciona facilidades a los Equipos Agile (visión global en la empresa, sinergias propias de una corporación, gestión de riesgos sobre daños colaterales al resto de la empresa y sus productos), mantiene la pureza de los valores y principios del Manifiesto Agile, y ofrece un camino progresivo de agilización de la empresa, facilitando la convivencia entre el modelo clásico y el nuevo modelo.

1.5 Descripción de una Agile Corporation

La Empresa Agile es aquella que, sabedora de su complejidad, basa su gestión en la delegación de su operación en modelos empíricos locales, para maximizar así su agilidad en la creación de valor al cliente y en el aprovechamiento de las oportunidades de los cambios en su entorno, con una gestión corporativa global de riesgo y mediante el aprovechamiento de sinergias, asegurando la rentabilidad futura para la propiedad.

Todo esto se consigue defendiendo y priorizando los siguientes valores del Manifiesto Agile:

1. Personas y Relaciones sobre Procesos y Herramientas

2. Entregas de Valor al Cliente sobre Protocolos Internos*

3. Colaboración con el Cliente sobre Seguimiento de Contrato

4. Adaptación al Cambio sobre Seguimiento de un Plan

* En agilecorporation.org hemos reescrito el segundo valor para referirlo no sólo al software, sino a cualquier entrega de valor hecha por el equipo.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Adicionalmente hay que añadir dos valores nuevos, para compatibilizar el modelo Agile con las necesidades de una corporación:

5. Gestión del Riesgo sobre Control por Aprobación

6. Verdaderos Servicios Internos sobre Imposiciones Corporativas

Nos gusta representar esta corporación Agile mediante una gráfica con un conjunto de triángulos encajados a modo de Matrioshka, como se puede ver en la figura adjunta. Unos primeros triángulos verticales representan los equipos de trabajo en productos, donde la propiedad del producto se transmite desde las células de ideación a las células de desarrollo y operaciones, todas ellas coordinadas, como veremos durante los capítulos siguientes. La gestión del producto es Agile en el sentido de preservación de los valores del manifiesto. Todos estos triángulos que representan los distintos productos conforman el triángulo del área de productos, que estará centrada en el cliente, y que poseerá la agilidad suficiente como para permanecer centrada en él todo el tiempo.

La Corporación Agile

A la derecha del dibujo tenemos las áreas de expertise, desde donde se proporcionan los servicios internos en forma de paved roads o carreteras asfaltadas, un modo de servicio que preserva la agilidad en los equipos, como explicaremos en los últimos capítulos. Estas áreas de servicio también contienen las cadenas de montaje, las fábricas, así como los controles en forma de gestión de riesgos por umbrales. Todo esto se detallará durante el desarrollo del modelo en los siguientes capítulos.

En la cúspide cerramos el esquema con un pequeño triángulo que representa lo que llamamos el Agile Board, que no es otra cosa que la representación de la propiedad en el modelo. Esta área estará centrada en los intereses de la propiedad, del accionista. Obviamente, lo ideal es buscar un alineamiento paralelo entre los ejes centrados en el cliente y en el accionista.

De esta forma, podemos decir que la Agile Corporation:

• Está centrada directamente en el cliente.

• Crea, modifica, corrige e incorpora funcionalidad con agilidad tomando como base las impresiones y experiencias directas del cliente.

• Esto lo hace con sus equipos de producto, cuya agilidad sólo se ve mermada por los flexibles y livianos mecanismos que garantizan el alineamiento con los intereses de la propiedad.

Esto es un cambio con respecto a la empresa eficiente. Como decíamos, no es que no esté centrada en el cliente. Sí lo está, pero de forma indirecta, pues enfoca todas sus áreas transversales en sus Productos y Servicios, cuyo destinatario es finalmente el cliente, no obstante, este enfoque ocasiona que la retroalimentación procedente del cliente sea también indirecta y tarde más en plasmarse en versiones modificadas de dichos productos y/o servicios. Es decir, intenta centrarse en el cliente, pero no tiene la agilidad para seguir centrada en él ante cambios, debido a las necesidades de coordinación entre departamentos funcionales.

Volviendo a nuestra representación de la Agile Corporation en la figura anterior, se puede ver que un propósito de mejora continua y un mecanismo de gestión de la transformación impera en toda la empresa, incluso después de haber llegado supuestamente al máximo de agilidad. Y es que la agilidad no es una meta en sí misma, sino una forma de alcanzar las metas que la empresa persigue.

Como adelantábamos al principio del texto, el ACF se nutre principalmente de dos teorías, que analizaremos en los dos capítulos siguientes:

• Self Determination Theory (SDT), que muestra el problema que supone implantar Agile en las corporaciones, ya que las necesidades esenciales para la motivación del individuo resultan limitadas por los controles, las sinergias impuestas y las jerarquías de la empresa eficiente. SDT es la teoría de la motivación humana y la personalidad y resalta que lo importante para el funcionamiento de una empresa son los individuos que la forman.

• Complexity Theory (CT), que nos da pistas de la solución al problema en cuestión con los modelos de Sistemas Complejos Adaptativos (CAS), que permiten salvaguardar en gran medida las necesidades esenciales, manteniendo el alineamiento con la propiedad.

El ACF es un Ecosistema que se puede implantar de forma parcial en la empresa, lo que permite su incorporación de forma progresiva y sin riesgos. Este ecosistema, aunque está pensado para corporaciones, es válido para cualquier tamaño de empresa y es más simple de lo que parece en su concepción.

1.6 Combinación Inteligente Agilidad & Alineamiento

En nuestro modelo ACF vamos a analizar el concepto de agilidad, que definiremos más en detalle en el capítulo sobre Agile, pero que ahora podemos entender de forma intuitiva como el grado de cumplimiento de los valores de Agile en nuestra organización, valores que figuran en el Manifiesto Agile y que han sido mencionados anteriormente.

Estos valores nacieron en el mundo del desarrollo software, no obstante, actualmente se aplican a cualquier tipo de proceso empresarial. De ellos se derivan los siguientes doce principios rectores, que son las herramientas para poner los valores en práctica y que también hemos adaptado a cualquier tipo de producto, no sólo software:

1. Nuestra mayor prioridad es satisfacer al cliente mediante las entregas tempranas, continuas y con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos con una frecuencia determinada y preferentemente en el período de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

7. Las entregas que aportan, que son operativas, constituyen la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su comportamiento en consecuencia.

En este libro agilidad es una palabra reservada y no responde sólo al concepto de dinamismo o rapidez de respuesta de un sistema o de una organización, sino a la cobertura de dichos valores Agile, pues una hipotética empresa 100% Agile los cumpliría también al 100%.

En nuestro modelo también utilizamos el concepto de alineamiento, como la característica de que las partes actúen de forma acompasada con el propósito o los planes de la organización, con los intereses del accionista. A partir de ahora, nos referiremos al propietario o accionista como la Propiedad. En una hipotética empresa 100% alineada todas las partes (individuos, departamentos y otros colaboradores) actuarían cumpliendo escrupulosamente el propósito y los planes diseñados por la Propiedad.

Es fácil hacerse la idea de que una empresa nunca podría conseguir un 100% de alineamiento. Eso significaría que los dueños, los accionistas, o el board, diseñarían y planificarían de forma absoluta la forma de actuar de todos las partes de la empresa, con nula delegación en sus subordinados. La delegación en una parte implicaría la reinterpretación del propósito y los planes globales por dicha parte, y entonces se podría llegar cerca del 100% si se explica muy bien como dueños, pero nunca sería realmente del 100%.

Del mismo modo, una empresa que alcanzara el 100% de agilidad dotaría de libertad y autonomía absoluta a todas las partes. Una directriz o una limitación, aunque fuera presupuestaria, ya supondría una reducción de su agilidad, como veremos más adelante. Es fácil deducir entonces que si una empresa tuviese un grado de agilidad del 100% sería un caos.

Si obviamos las situaciones extremas y utópicas explicadas anteriormente, podemos imaginarnos empresas muy Agile y empresas muy alineadas. Podemos decir que una empresa tiene total grado de agilidad cuando aplica Agile en toda la organización. También podemos decir que una organización tiene alineación total cuando hay una rígida estructura jerárquica tipo Jefe-Empleado, en la que cualquier delegación está acompañada de estrictos controles para asegurar el alineamiento de dichas decisiones delegadas.

En el capítulo de Teoría de la Complejidad intentaremos demostrar que una empresa con alineamiento total tiene una mínima capacidad de adaptación y por tanto no resulta viable en un mundo cambiante. Del mismo modo veremos en el capítulo de Gobierno que una organización con agilidad total tendrá dificultad para alinear el propósito de sus componentes con el propósito de la Propiedad. Por lo tanto, en cierto modo tampoco será viable desde el punto de vista del accionista. En resumidas cuentas, el alineamiento es bueno y la agilidad es buena, pero un grado total de una de ellas es incompatible con un grado total de la otra. Esta es la explicación teórica por la cual las implantaciones de Agile en las corporaciones están fracasando y terminan siendo un caos, o bien, poco Agile.

Como corolario, podemos afirmar que el ACF es un marco de trabajo que sirve para encontrar en cada empresa el modelo organizativo en el que se maximice de forma simultánea el grado de agilidad y alineamiento, teniendo en cuenta lo siguiente:

• Una empresa con 100% de agilidad y 0% de alineamiento no funciona.

• Tampoco sobrevive una empresa con 0% de agilidad, aunque tenga 100% de alineamiento.

• Una empresa con 50% de agilidad y 50% de alineamiento es fácil de conseguir, pero poco competitiva.

• Finalmente, para que una organización sea competitiva, tiene que buscar tener Agilidad y Alineamiento próximos al 100% y con el ACF esto es posible.

Pero todo lo dicho anteriormente no debe aplicarse a la organización como si ésta fuera un ente indivisible. Más adelante veremos que las organizaciones, quieran o no, son sistemas complejos compuestos por partes que siempre tienen algún grado de autonomía. En las empresas poco ágiles esta autonomía será baja, y en las muy ágiles todo estará muy delegado y será máxima.

En cada organización algunas áreas pueden ser muy ágiles y otras pueden estar muy alineadas según convenga, entendiendo que ambas cosas al 100% son imposibles, aunque el máximo valor de ambas es deseable.

Puede ocurrir como en el ejército moderno, en el que hay cuerpos muy alineados y poco ágiles, que siguen directrices muy estrictas porque los riesgos de error no podrían ser asumidos, o cuerpos que reciben la misión, su propósito, y actúan con total autonomía adaptándose a las circunstancias y tomando decisiones propias dentro de las reglas establecidas o en el límite de las mismas, como ocurre con los cuerpos de élite.

También puede ocurrir como en las empresas de distribución modernas, en las que sus repartidores deben cumplir procesos estrictos de reparto, pero a la vez tienen autonomía absoluta para tomar decisiones en tiempo real para resolver situaciones especiales que encuentren durante su ruta.

Como conclusión, el gobierno de la empresa moderna debe en sí mismo adoptar agilidad para determinar la mejor organización para cada caso.

2 Generalidades del Modelo

El objetivo de este capítulo es presentar las generalidades del Modelo Agile Corporation Framework (ACF), cuyo propósito es maximizar la agilidad y el alineamiento dentro de la empresa, sirviendo como resumen de lo que después se irá analizando en detalle durante el resto de los capítulos del libro. La exposición del modelo es progresiva, por lo que ciertos conceptos se irán explicando en profundidad a medida que se avance en la lectura. El propósito es dar una idea general que sirva de referencia al lector mientras se detallan los conceptos específicos de cada capítulo.

Es evidente que una empresa no puede pasar de funcionar con filosofía jerárquica clásica a hacerlo con filosofía Agile de la noche a la mañana, por lo que la transformación requerirá una fase transitoria que habrá que gobernar. Esto lo hemos tenido siempre presente durante la confección del modelo y queremos tratarlo de forma temprana porque es una de las primeras preguntas que surgen cuando empezamos a explicarlo.

La situación de partida consiste en habilitar un Ecosistema Agile Inicial, o Agile Ecosystem Zero (AEZ), como veremos más adelante, que constará sólo de un departamento, un área, un conjunto de equipos Agile, etc. Este ecosistema cumplirá de partida con el modelo ACF que vamos a exponer, trabajando de forma integrada en la empresa jerárquica y con mecanismos de comunicación y relación con ella. Si representamos la corporación como un triángulo, nosotros vemos al AEZ, como un pequeño triángulo dentro del triángulo de la corporación, con pequeños conectores específicos que posibiliten su comunicación y su funcionamiento operativo, pero con la suficiente impermeabilidad como para preservar una forma de trabajar Agile. El funcionamiento detallado de esta integración se verá más adelante.

La idea obviamente es que este ecosistema Agile inicial o Agile Ecosystem Zero, vaya creciendo, incorporando más equipos de trabajo. Conforme crezca pasará a denominarse Agile Ecosystem Zone, conservando no obstante sus siglas AEZ.

Teniendo presentes ambos modelos, el clásico y el ACF, enumeremos ciertas características de nuestro Marco de Trabajo:

• La empresa se organizará en equipos compuestos por células de 7 u 8 miembros. Usaremos el nombre de células cuando nos refiramos al grupo de individuos estable, de identidad concreta y que, como veremos, se autogestiona por sí mismo dentro de las limitaciones que garantizan su alineamiento dentro del equipo. Por otra parte, usaremos el término equipo para referirnos a un conjunto de células que colaboran para un propósito común. Como veremos, el término equipo es más ambiguo y su delimitación depende del ámbito del propósito que consideremos.

• Estas células y equipos funcionarán entre sí como un Sistema Complejo Adaptativo. Este concepto se verá en el Capítulo 3, pero adelantamos ya que es un funcionamiento incómodo para el defensor a ultranza de la empresa jerárquica. Digamos que se trata de una forma de funcionar en la que, una vez establecido el propósito alineado con los intereses de la empresa, la célula o equipo se autogestiona adaptándose a la complejidad del entorno y buscando un equilibrio en el sistema.

• Como resultado de lo anterior, el ACF requerirá un modelo de gestión muy diferente al clásico, requiriendo asimismo un modelo de gobierno específico.

• Las células y equipos del ACF pertenecerán a tres áreas de trabajo, en función del propósito de cada equipo: Áreas de Producto, Agile Board y Áreas de Expertise, como veremos más adelante.

Aunque el detalle del modelo se explicará en capítulos posteriores, este capítulo no es meramente canónico, pues además de exponer los fundamentos del ACF para que se entiendan y sirvan de base, también pretende que el lector los asimile y analice la viabilidad de la aplicación del modelo a su empresa en particular.

Pasemos pues a descomponer el ACF en cuatro capas, que se expondrán en las secciones posteriores de este capítulo:

• Capa de Composición, donde detallaremos las características de las células que componen el AEZ.

• Capa de Complejidad o Escalado, donde detallaremos cómo las células interaccionan entre ellas y con el resto del ecosistema.

• Capa de Organización, donde detallaremos cómo se organizan las células según su propósito.

• Capa de Gobierno, donde detallaremos cómo se maneja o dirige este conjunto de células autónomas, que no independientes.

Al final de cada capítulo y como comentábamos al principio, se hará especial énfasis en el proceso de implantación del modelo en una empresa jerárquica ya existente, desde su inicio hasta su fin, pasando por la convivencia con la parte No Agile de la organización en cada momento.

2.1 Capa de Composición

Si entendemos la empresa como un sistema complejo y nos apoyamos en la Teoría de la Complejidad (Complexity Theory), que trataremos más en detalle en el Capítulo 3, podemos afirmar que en el ACF se gestionan:

• Los individuos como parte fundamental de una célula.

• Las células como parte fundamental de la empresa, es decir, del sistema.

En sentido estricto, veremos que la AEZ debería estar compuesta únicamente por células autónomas y multidisciplinares, cuya gestión no podrá ser plena, pero si máxima. Deberemos dotar a estas células de las maestrías necesarias para el propósito que tengan encomendado.

En estas células, o Equipos Autónomos Multidisciplinares …

• Se satisfacen las necesidades esenciales de la Teoría de Autodeterminación (Self Determination Theory) para la gestión inteligente de la motivación, como veremos más en detalle en el Capítulo 4.

• Se defienden e interiorizan los valores de Agile.

Pero dicho así, podría pensarse que no hay directivos y que por arte de magia las células alcanzan la máxima productividad y el alineamiento absoluto con el accionista, esto es, con la propiedad. En realidad, en el modelo ACF también hay gestores o directivos, aunque se organizan de forma diferente y adoptan una forma de actuar también diferente.

Para empezar, también se organizan en células. En el capítulo de Self Determination Theory veremos que trabajar en equipos autónomos multidisciplanes es la mejor forma de sacar el máximo provecho al trabajador del ámbito conceptual y creativo. Pues bien, el trabajo de un directivo también es conceptual y creativo, por lo que en realidad sus necesidades esenciales son las mismas y trabajarán mejor en estos equipos. Cuando estudiemos las Capas de Gobierno y Organización veremos cómo se puede distinguir a estas células del resto, así como los mecanismos de que disponen para cumplir con su propósito.

Volviendo a las células del ecosistema, éstas poseen las siguientes características:

• Tienen sentido de la propiedad sobre su misión y sobre su mejora continua.

• Están enfocadas a la acción y a aportar un valor al cliente.

• Tienen una comunicación fluida entre sus miembros.

• Incluyen Maestros, que son miembros que portan una maestría

• Tienen estabilidad en el tiempo.

• Son responsables de forma compartida de todas las decisiones y del desempeño del conjunto.

Esto constituye en sí una gran diferencia con la empresa jerárquica, pues siempre se nos ha enseñado que, para que algo funcione, debe haber una persona responsable de ello. Sin embargo, como veremos más adelante, el espíritu de la Self Determination Theory es justo el contrario, esto es, lo importante es precisamente que haya un equipo que se responsabilice de las decisiones compartidas.

El tamaño de estas células es importante. Pueden estar constituidas por una sola persona, pero coincidimos con Scrum Alliance cuando afirma que el tamaño ideal de una célula oscila entre los 3 y los 9 miembros, aunque esto dependerá evidentemente de cada propósito y de cada circunstancia. Además, cada célula evolucionará de forma natural, pudiendo aumentar de tamaño, decrecer, partirse en dos mitades, etc.

En las próximas secciones de este capítulo vamos a ver cómo se articula la convivencia de este conjunto de células Agile con el resto de la empresa jerárquica.

2.2 Capa de Complejidad o Escalado

En esta sección veremos cómo escalan los ecosistemas Agile cuando se añaden equipos a los mismos. En realidad, un sistema tiene distinta complejidad según la escala a la que se analice. Si nos centramos en una célula en particular tenemos su complejidad propia, con las particularidades y características de cada uno de sus miembros, la diversidad de los perfiles que la componen, la relación personal entre ellos, la organización y procesos que siguen, etc. Obviamente, para analizar la complejidad de toda la empresa a este nivel, la deberemos analizar de forma separada para cada una de las células que componen la corporación. Por otra parte, si aumentamos la escala, veremos a las células como unidades atómicas que están organizadas en productos o servicios internos o externos.

Sin entrar entonces en la complejidad de cada una de las células, podremos analizar cómo éstas interactúan entre sí para desarrollar cada producto. Veríamos entonces cómo se relacionan entre ellas, con qué artefactos, mediante qué ceremonias y cómo alinean sus propósitos en busca de un propósito común. Del mismo modo, si subimos de escala y dejamos de entrar en la complejidad de cada producto, podremos ver cómo éstos se relacionan entre sí formando las distintas áreas.

Fijándonos en las relaciones entre las partes, en el capítulo dedicado a la complejidad usaremos el concepto de interdependencia. De esta manera, para entender una célula necesitamos conocer a los individuos que la componen y las interdependencias que regulan su funcionamiento. Para entender a los equipos compuestos por células, necesitamos entender también a éstas y las interdependencias que regulan la coordinación entre ellas. Subiendo a escala de producto, las interdependencias que regulan la relación entre dos equipos son una abstracción de las existentes entre células de un equipo y otro. Y así progresivamente llegaremos a entender la AEZ a través de las áreas que la componen y sus relaciones, que serán una abstracción de las interdependencias existentes entre células de una u otra área.

En la Capa de Complejidad se explicará cómo al escalar el tamaño del ecosistema, éste empieza a comportarse como un Sistema Complejo Adaptativo. Y como hemos visto, no hablamos de jerarquías, sino de una red de interdependencias que coordinan el funcionamiento de las células, una red que constituye y posibilita el gobierno del conjunto.

Las Células en el ACF

La interdependencia, como relación que existe entre dos células, se define mediante los dos elementos siguientes:

• Un Artefacto, que es la pieza de información sobre la que se basa una relación o parte de ella

• Una Ceremonia, que es un acto reglado que sostiene la continuidad de la interdependencia, y en el que normalmente se usan los artefactos predefinidos

Como se verá en los siguientes ejemplos, estas interdependencias que definimos de forma ortodoxa como combinación de artefacto y ceremonia, representan la relación tradicional entre dos partes de la empresa, como pueden ser la relación entre el jefe y su departamento, o la coordinación entre dos departamentos distintos de la empresa. La formulación de la relación usando artefactos y ceremonias se debe a la necesidad de descomposición de la misma en sus partes fundamentales para analizarla mejor, debido a la gran importancia que tiene para el ACF la gestión de dichas relaciones.

Ejemplos de artefactos pueden ser:

• Un tablero Kanban, un backlog de producto, o cualquier otro de los artefactos usados en Scrum.

• Un prototipo Lo-Fi (Low-Fidelity).

• La certificación de poseer una maestría.

• Un indicador o cuadro de indicadores.

Ejemplos de ceremonias pueden ser:

• Cualquiera de las de Scrum, como el Daily, el Sprint Planning, etc.

• Un ciclo de ideación.

• Un concurso interno de innovación.

• Un comité de seguimiento.

Por otra parte, puede haber dos tipos de interdependencias:

• Las gestionadas, en las que hay un compromiso por ambas partes para mantenerlas y que están soportadas por artefactos y ceremonias definidos y establecidos. Tienen la ventaja de ser fácilmente gobernables para asegurar el alineamiento con la empresa.

• Las espontáneas, que son las que se realizan por propia voluntad de los actores, sin que estén coaccionados u obligados a ello. Tienen la ventaja de que preservan el 100% de agilidad.

Detengámonos un momento para reflexionar acerca del propósito de las interdependencias gestionadas. En el modelo ACF los ecosistemas utilizan este tipo de interdependencias para implementar los controles, para garantizar el aprovechamiento de sinergias y también el gobierno del sistema, es decir, para asegurar el alineamiento de cada equipo con el propósito de la empresa.

Sin embargo, si observamos el sistema a escala celular, comprobaremos que la mayoría de las interdependencias son espontáneas, esto es, que no están regladas ni son obligatorias. Como veremos en la sección de Gobierno, aunque estas interdependencias no estén documentadas, en realidad son las ideales de cara al alineamiento y la agilidad.

Por lo que respecta al tamaño, si una célula crece por necesidad y supera el número máximo de 9 miembros, dicha célula deberá partirse. Esta partición no implicará que dejen de existir las interdependencias ya existentes entre los miembros que queden en ambas partes de la célula, por lo que también tendrá que haber interdependencias entre las dos nuevas células resultantes. No obstante, en este caso hay un matiz importante: las interdependencias originalmente espontáneas deberían pasar a ser gestionadas, con objeto de garantizar que los propósitos de ambas células siguen correctamente alineados con el paso del tiempo.

Para continuar con nuestro análisis, consideremos el caso de una gran corporación funcionando con filosofía Agile ya en régimen permanente. Al tratarse de un sistema complejo, tendríamos cientos de células interactuando unas con otras, aunque también apreciaríamos una gran complejidad si viéramos el organigrama jerárquico de una empresa cualquiera en una sola página. En el primer caso se trataría de un sistema complejo adaptativo, cuyo escenario se estudiará en la sección de Gobierno, para ver cómo se simplificaría en gran medida la gestión del alineamiento, permitiendo ganar autonomía a las células.

Lo anterior aplicaría al ecosistema Agile, pero veamos qué ocurriría con la relación entre las células de este ecosistema y el resto de la empresa que funciona con filosofía No Agile.

Cualquier Sistema Complejo Adaptativo se relaciona con el exterior, a través de diversos mecanismos. Por ejemplo, si toda la empresa fuera un CAS tipo Agile existirían interdependencias con las entidades externas, tales como Clientes, Proveedores, etc. Para garantizar el buen funcionamiento de las relaciones en cuestión, lo más habitual en las empresas es que dichas interdependencias sean Gestionadas, en vez de Espontáneas, puesto que de esta forma existirá un compromiso de mantenerlas para asegurar el alineamiento con la empresa.

El ecosistema Agile también puede tener relación con la parte No Agile de la empresa. Como en el caso anterior, la clave de una buena integración entre ese ecosistema y el exterior es que las relaciones que existan estén siempre gestionadas.

Aunque el resto de la empresa no se verá afectado, el equipo directivo que gobierne la parte No Agile deberá pilotar y documentar el ecosistema con base en estas interdependencias gestionadas. Para ello, las interdependencias deberán diseñarse para cumplir el objetivo primordial de alineamiento máximo, beneficiando a la Agilidad en la medida de lo posible.

2.3 Capa de Organización

En esta capa analizamos cómo está organizado un ecosistema Agile. Como hemos visto hasta el momento, todo el ecosistema está formado por células, incluso en el caso de los mecanismos de Dirección. Además, las interdependencias entre dichas células nos permiten escalar el sistema.

Si nos quedásemos aquí, todo el ecosistema quedaría como una masa invertebrada y uniforme de células interrelacionadas, donde sería difícil encontrar un orden. El sistema complejo adaptativo de esta empresa sería parecido al del tráfico, o al de un bosque, con multitud de elementos independientes que siguen unas reglas, que buscan un equilibrio, pero que carecen de un alineamiento común. Nuestro sistema complejo adaptativo deseado debería ser, sin embargo, más parecido a un sistema inteligente, como un ser vivo, con partes del sistema específicas y una especialización concreta. Pues bien, en este caso vamos a ver cómo las células del ecosistema se organizan en equipos, y éstos a su vez pertenecen a una de estas tres áreas principales según el tipo de propósito que persigan:

• El Agile Board, donde están las células que garantizan el valor para el accionista.

• El Área de Productos, donde están los equipos que generan valor para el cliente.

• Las Áreas de Expertise, donde están los equipos que facilitan la generación de valor mediante servicios internos para el resto de las áreas.

Normalmente, en nuestra representación de la Agile Corporation (ver la figura del triángulo en el Capítulo 1) representamos las áreas de la forma siguiente:

• El área de producto como la más extensa, en la parte central/izquierda de la figura.

• El Agile Board como una cúspide pequeña en la parte alta del triángulo.

• Las Áreas de Expertise como una secuencia de romboides que sirven de franja en la parte derecha de la figura, para completar la pirámide.

Estas áreas se diferencian según el propósito de sus células, como hemos comentado, pero no están separadas unas de otras. Las interdependencias entre células cruzan los límites entre estas tres áreas, rompiendo así con los silos departamentales, pues lo natural es que todas las células tengan relación con las células de las otras áreas. A continuación, analizaremos la composición de cada una de estas áreas.

El agile board es el mecanismo que acerca la propiedad a las operaciones, velando por el gobierno global, el alineamiento, la agilidad, los patrones deseados y el liderazgo servil. Lo normal es que sea un área muy pequeña, dado que toda la responsabilidad sobre el producto se ha cedido a las células de los equipos del Área del Productos, como veremos a continuación. Está compuesto, a su vez, por dos tipos de células con dos funciones que idealmente deberán estar separadas:

• Las células de Corporate Angels, que velan por el alineamiento.

• Las células de Agile Coaches, que velan por la agilidad. Es importante reseñar que en este libro utilizamos el término “Agile Coach” para referirnos a los especialistas en Business Agility y especialmente en el ACF, en vez de referirnos a los “entrenadores” para metodologías de desarrollo de SW Agile.

El área de productos está dividida a su vez en Equipos de Producto compuestos por células, algunas más de ideación, otras más de desarrollo, que se coordinan entre sí mediante artefactos y ceremonias. El alineamiento y agilidad de estos equipos se gobierna mediante las interdependencias que éstos tienen con las células del Agile Board.

Si analizamos la organización dentro del área de productos nos encontraremos con un ordenamiento por productos, como no podría ser de otra forma, Pero también podremos identificar otra diversidad de elementos. Por ejemplo, encontraremos equipos compuestos por células que tengan una identidad propia, un propósito de construir un elemento concreto, pero que no constituya de por sí un producto completo, sino que desarrolle parte de él, un subproducto. Y si dicho elemento se utilizara en más de un producto diferente, entonces deberíamos decir que dicho equipo trabaja en un componente. Si bien puede parecer una organización banal de tipos de equipos, debemos advertir que no es así y que el tipo de interdependencias y la forma de aportar valor al cliente final es bien distinta dependiendo de cada uno de esos tipos.

Las áreas de expertise son como las áreas de producto y se configuran de forma parecida. Sin embargo, en este caso los clientes son internos. Veremos que los llamados maestros son individuos de las células de producto que tienen además el rôle de usuarios principales para las células del Área de Expertise. Los servicios y productos de estas áreas poseen características muy específicas, pero al igual que pasa con todo lo dicho en este capítulo, los analizaremos más en detalle durante el desarrollo del libro.

2.4 Capa de Gobierno

En esta sección veremos cómo se gobiernan los ecosistemas Agile, lo cual constituye la cuarta y última capa del modelo ACF. Como hemos visto en las secciones anteriores, todo ecosistema Agile está formado por células, incluso en el caso de los mecanismos de Dirección. Asimismo, mediante interdependencias se alinean las células formando estructuras más complejas, se implementan los controles y se maximiza el aprovechamiento de las sinergias. Por lo que respecta a la Capa de Gobierno, su implementación también se basa en interdependencias, pero además consideraremos un componente adicional: las mecánicas de motivación extrínseca.

Como veremos en el Capítulo 4, las necesidades esenciales de la Teoría de Autodeterminación cubren la motivación intrínseca y están ya consideradas gracias a la constitución de células en forma de Equipos Autónomos y Multidisciplinares, con un propósito propio. Sin embargo, las interdependencias que regulan las relaciones entre estas células para alinearlas con un propósito común menoscaban en cierta medida dichas necesidades esenciales, como vimos al hablar de escalado. Por tanto, nos encontramos con una dicotomía difícil de abordar donde, por una parte, queremos dar autonomía a las células para preservar su agilidad y, por otra, establecemos interdependencias que coartan en cierta forma dicha autonomía para alinearlas con los intereses de la empresa. Así pues, será importante que al definir estas interdependencias para el gobierno del ecosistema elijamos aquellas que preserven las necesidades esenciales, su agilidad, en la mayor medida posible.

Esto nos lleva al primer yin-yang necesario para definir el Gobierno del ecosistema: el yin-yang de la Gestión del Propósito. Se refiere a la búsqueda de convergencia entre Alineamiento y Agilidad, sabiendo de antemano que ninguno de ellos puede llegar a ser el 100%, y que son opuestos. Cada interdependencia entre dos células implica un mayor grado de alineamiento, pero también una limitación de la agilidad en cada una de ellas. Si se trata de una buena interdependencia, el grado de alineamiento que ésta implique será máximo y la limitación de agilidad será mínima. Respecto a esto, recordemos que las interdependencias que tienen lugar entre los miembros de una propia célula suelen generar máximo alineamiento con mínima limitación de agilidad, al ser del tipo “no gestionadas”.

En la próxima sección veremos cómo hay células que velan por el alineamiento, las compuestas por los llamados Corporate Angels, y células que velan por la agilidad, las compuestas por los Agile Coaches. Estas interdependencias, gestionadas por ambos tipos de gestores, están dirigidas a conformar el propósito final y autónomo de cada equipo, alineándolo con los intereses de la Propiedad, de ahí su nombre. Dos herramientas importantes para este alineamiento, que no perjudican la agilidad, son los Paved Roads y el Risk Threshold Management, que veremos en detalle más adelante.

Pero en nuestro modelo de gobierno hay una segunda dicotomía que resolver, aquella que, por una parte, fomenta una cultura uniforme con unos valores específicos favorables para la empresa, y por otra fomenta el liderazgo individual de los miembros de las células, generando los líderes serviles tan necesarios en un ecosistema Agile. Se trata del Yin-Yang de la Gestión del Comportamiento. Y es que a la hora de buscar soluciones a problemas que son complejos en su conjunto, pero abordables en lo específico, buscamos la uniformidad entre determinados valores, pero defendiendo el libre albedrío del individuo. Tomando como referencia los fundamentos de los sistemas complejos adaptativos, comprobaremos que las mecánicas de motivación extrínseca resultan ser una buena herramienta para promover tanto los patrones de homogeneidad como la individualidad de los líderes, estando dirigidas a modelar los comportamientos a nivel general. Por ejemplo, el reconocimiento de los maestros en una materia específica es una forma de potenciar su liderazgo (esto lo veremos más adelante). El surgimiento natural de líderes en sí mismo es un fenómeno que debe buscarse mediante estas mecánicas de motivación extrínseca. A estos comportamientos extendidos en el ecosistema los llamamos Patrones, pues se corresponden con la cultura de la empresa y son una propiedad emergente del sistema complejo que gestionamos.

Hablando de cultura y como es sabido, para investigar la que es específica de un lugar al que se acaba de llegar, hay que preguntar al más viejo del lugar cómo se sobrevive allí. Veamos algunas posibles respuestas a esta pregunta, que denotan la existencia de patrones negativos, siempre en lo relativo a la agilidad:

• “Aquí ten cuidado con discutirle a un Director, tienen mucho poder”

• “Aquí es importante que te vean en la oficina”

• “Aquí todo por escrito, que si no termina siendo culpa tuya”

• “Pide cinco de más, que luego te exigen siempre gastar menos”

• “Para qué molestarnos en pedir, si nos lo van a denegar”

Sin embargo, veamos también posibles respuestas que denotan patrones deseados, también en cuanto a la agilidad. Además de los juicios contrarios a los anteriores, podríamos tener los siguientes:

• “En las reuniones de aquí no sabes nunca quién es el jefe”

• “Aquí es importante aportar siempre, aunque te equivoques”

• “Si no sabes, pregunta”

• “Si necesitas ayuda de un departamento, ve y la pides directamente”

• “Oye, ¡qué buena idea! ¡proponla!”

Las mecánicas de motivación extrínseca, que tan bien aplican a la modelización de patrones, se explicarán más en detalle en el capítulo de gobierno, no obstante, para darnos una idea del tipo de mecánicas a las que nos referimos, veamos ahora algunos ejemplos:

• En el entorno competitivo o de juegos tendríamos: ranking, concursos, insignias, etc.

• Como mecánica reputacional podríamos tener un sistema de reconocimiento y liderazgo, como individuo o como equipo, bien por las maestrías, bien por sus aportaciones.

• Como mecánica social tendríamos la motivación personal de aportar ideas en foros o laboratorios, así como ofrecer soporte desinteresado a quién lo solicite.

• Y, por supuesto, no podemos dejar fuera como ejemplo la política retributiva.

Estas mecánicas deben analizarse y diseñarse con sumo cuidado. En la sección del Capítulo 3 (Complexity Theory) dedicada a la Teoría del Caos, vamos a ver que estas medidas pueden ser contraproducentes e incluso volverse peligrosas con suma facilidad, por lo que sugerimos el estudio de técnicas de gamificación para su elaboración.

En cuanto a cómo convive el ecosistema con el exterior, la iniciativa de montar un ecosistema Agile dentro de la empresa sólo tendrá sentido si la propiedad de la empresa realmente cree en el modelo. En dicho caso, durante la coexistencia de ambos modelos deberán establecerse en paralelo otros modelos de gestión similares a los sugeridos para el ecosistema Agile anteriormente, así como mantener los modelos de gobierno tradicionales para el resto.

Sin embargo, se verá de forma natural que las mecánicas de gobierno del ACF serán bienvenidas también en el área de la empresa No Agile, por lo tanto, lo normal es que tras poner en marcha el Gobierno del ACF, éste se extienda de forma natural al conjunto de la empresa, aunque ciertas áreas estén sujetas a interdependencias jerárquicas más estrictas que otras.

2.5 Convivencia del ecosistema con la empresa jerárquica

Por lo que respecta a la convivencia del ecosistema Agile con la parte No Agile de la empresa, hay que tener en cuenta que la parte Agile estará basada en su composición en células y su relación mediante interdependencias. Por tanto, sus relaciones con la parte jerárquica también estarán basadas en interdependencias, aunque en este caso el extremo de la interdependencia será un individuo concreto, con una responsabilidad concreta en la parte No Agile de la empresa. Esto es perfectamente compatible con la existencia de un gobierno propio efectuado por las células del Agile Board del ecosistema. A continuación, veremos cómo nace dicho ecosistema y cómo se extiende la cultura Agile por la empresa.

En un primer momento, como ya mencionamos al comienzo de este capítulo, tendremos lo que denominamos Agile Ecosystem Zero o AEZ. Este ecosistema podría no tener aún un Área de Expertise, y el Agile board podría estar compuesto sólo por un par de personas, una de las cuales tendría el rôle de Corporate Angel, que sería un directivo de la empresa jerárquica, y la segunda el rôle de Agile Coach, que podría ser un perfil subcontratado a un especialista en agilidad en corporaciones.

La empresa jerárquica en cuestión debería trazar una estrategia de crecimiento para el AEZ con el objetivo de incorporar nuevos equipos de producto al área de productos del ecosistema, para lo cual deberían analizar las interdependencias con la empresa jerárquica según el sistema de Yin-Yang de Gestión de Propósito (Agilidad y Autonomía). También debería definir nuevas áreas de expertise que se formarían a partir de los departamentos de servicios internos actuales de la empresa jerárquica, pero transformando sus servicios sinérgicos de forma que fueran compatibles con la agilidad de los equipos a los que atienden. A este tipo de servicios internos los llamamos Paved Roads, o carreteras asfaltadas, y los analizaremos en detalle en el capítulo de áreas de expertise.

Tres actividades paralelas tendrían lugar al mismo tiempo:

• Se revisarían los controles, adecuándolos a una nueva política de gestión de riesgos por umbrales, una forma menos intrusiva de mitigar el riesgo que un equipo Agile puede causar al resto de la empresa.

• Se revisarían las mecánicas de motivación extrínseca apoyadas en el Yin-Yang de la Gestión de Comportamientos (Patrones y Liderazgo).

• Finalmente, se adaptaría el Agile Board a las exigencias resultantes del cambio en el resto de las áreas.

En un momento dado, el ecosistema AEZ cambiaría el sentido de su letra Zeta, dejando de ser Agile Ecosystem Zero para pasar a denominarse Agile Ecosystem Zone. En cualquier caso, el ecosistema deberá verse como algo limitado pero interconectado dentro de la empresa jerárquica, a través de interdependencias gestionadas mediante artefactos y ceremonias.

3 Complexity Theory

3.1 Introducción a la Teoría de la Complejidad

La Ciencia de la Complejidad estudia los denominados Sistemas Complejos considerando su realidad difusa, polivalente, multinivel y multidisciplinar. Estos sistemas se analizan en profundidad tratando de identificar patrones comportamentales o reglas dentro de su complejidad, con objeto de intentar describir la evolución potencial a futuro y poder tomar las decisiones adecuadas en cada momento.

Esta ciencia reúne a su vez un conjunto de disciplinas tales como la Teoría de Sistemas Complejos Adaptativos, la Teoría de la Autoorganización, la Teoría de Juegos, la Teoría del Caos, la Teoría de Redes, el Efecto en Cascada (o Efecto Mariposa), etc. y se basa en ellas para constituir la Teoría de la Complejidad (Complexity Theory, en adelante CT). El objetivo de este capítulo es buscar en dicha teoría la inspiración necesaria para encontrar la estrategia de gestión que deberíamos emplear en una empresa Agile, la cual, como veremos más adelante, es en sí misma un Sistema Complejo Adaptativo. En realidad, cualquier empresa es un sistema complejo. Lo que variará es la característica de adaptación al entorno cambiante, lo cual implicará que sea más o menos viable su supervivencia en el tiempo.

Todo esto lo vamos a ir descubriendo en este capítulo, pero empecemos por lo más esencial. CT nace pues como resultado de los esfuerzos de los investigadores para desvelar el orden oculto existente en los sistemas complejos, pues éstos resultan viables, y aprovecharlo para controlarlos al máximo. Yendo ya a nuestro terreno, decíamos que es un hecho que la complejidad es una condición natural de la empresa como sistema complejo que es, y no es un deseo ni nada que se busque o se persiga en especial. Sin embargo, es algo que necesitamos controlar o gestionar, tanto para evitar situaciones que puedan poner en riesgo al propio Sistema (la empresa), como para fomentar su evolución en una dirección favorable para la Propiedad (los accionistas). 

Stephen Hawking decía que el siglo XXI es el siglo de la complejidad, en referencia a la CT de C.K. Chui (2000). Según expone Jurgen Appelo en su libro Management 3.0, éste es asimismo el siglo en el que los gestores comprenden que, para gestionar la complejidad social de la empresa, necesitan comprender también cómo crecen las cosas y no sólo cómo están construidas. Appelo explica que no se gestiona una empresa como cuando se construye un coche y se conduce por una ruta prefijada, sino como cuando se diseña un jardín, se planta, se riega, se poda y se dirige el crecimiento de sus plantas de forma constante. Esta es precisamente la clave de la Agilidad, es decir, el control permanente a base de pequeños incrementos. Un jardín, sí, pero de bonsáis.

En resumidas cuentas, nuestra intención al incluir CT como una de las bases de nuestro modelo es intentar ayudar a los gestores a mantener el delicado equilibrio entre el orden (la planificación, lo legal) y el caos (el azar, lo accidental) en sus empresas, mediante el uso de una estrategia organizacional en constante evolución, que se anticipe a los eventos y coyunturas, y que responda a las condiciones cambiantes del entorno y a la permanente retroalimentación de información debida a la interacción con el mismo.

Como es natural, el contenido del presente texto no pretende exponer CT con la extensión y el rigor canónico habituales en los artículos y libros específicos de la materia. Nuestro objetivo es darle un enfoque pragmático, por lo que sólo extraeremos de ellos un resumen de sus fundamentos, sus análisis y sus conclusiones, que nos servirán para sustentar el Marco de Trabajo de Agile Corporation.

3.2 Entendiendo los Sistemas Complejos

Entendamos primero qué son los Sistemas Complejos, formados por múltiples partes autónomas, aunque no independientes. Por lo general, existe un control central muy débil, por lo que las partes que los forman siguen un mínimo de especificaciones conjuntas. Por otra parte, una característica particular de todo sistema complejo es que de él emergen propiedades que no poseen las partes por sí mismas, como veremos más adelante. Las partes que integran estos sistemas compiten y cooperan entre ellas consiguiendo que el sistema a su vez compita y coopere con su entorno exterior, adaptándose en busca de su propia supervivencia.

Sistemas Complejos que funcionan son, por ejemplo, un bosque, el cuerpo humano, una colmena de abejas, las ciudades, o Internet. No es posible encontrar ejemplos de sistemas complejos que no funcionen por una sencilla razón: se habrían extinguido. De hecho y por lo general, un sistema complejo funciona siempre hasta el momento de su extinción, que se suele producir en el momento en que ya no es capaz de adaptarse a los cambios del entorno circundante que, por otra parte, se encuentra en constante evolución. Este razonamiento debemos aplicarlo cuando analizamos nuestra propia empresa. Es un sistema complejo y existe porque, de alguna forma, ha sido viable y ha conseguido sobrevivir, al menos hasta ahora.

Los Sistemas Complejos

Primera conclusión parcial para nuestro estudio: la empresa productiva del mañana será un sistema complejo cuya supervivencia en el entorno cambiante actual y futuro se deberá a la ventaja competitiva que habrá emergido de ella gracias a las partes que la integran, y gracias a los individuos que compiten entre sí y que colaboran en ella.

CT fue propuesta por investigadores que intentaban racionalizar y explicar el comportamiento de los sistemas grandes y complejos, ya que se creía que éstos no podían explicarse sólo con la ayuda de las reglas de la naturaleza. Los estudios resultantes intentan brindar una comprensión acerca del número de elementos que trabajan juntos para crear el sistema en sí y sus resultados asociados. Además, los estudios se centran también en cómo cambia cada elemento con el tiempo y qué influencias tiene esto en los otros componentes.

Los fundamentos de la CT consisten en que existe un orden invisible en el comportamiento y en la evolución de los sistemas complejos. Puede tratarse de economía nacional, de organizaciones o de líneas de producción que se perciben como sistemas. En el campo de los negocios la atención se centra en la semejanza de una empresa o fábrica con un ecosistema, en lugar de con una máquina. De la misma forma que un ecosistema responde a las leyes naturales para mejorar su adaptación, una empresa lo hará para encontrar las mejores soluciones posibles para sus problemas. Por tanto y de acuerdo con la CT, los gestores que se esfuercen en comprender las leyes de la naturaleza aprenderán que, si se deja que un sistema funcione por sí solo, por lo general se acabará organizando solo.

Y es que adaptación implica evolución y etapas y, por ende, orden. Así pues, cualquier sistema que evoluciona atraviesa algunas etapas siguiendo un orden concreto, lo cual ocurre también cuando se trata de empresas. CT, sin embargo, reúne dos conceptos opuestos, el orden y el caos. En esta línea de razonamiento, Stuart Kauffman es un biólogo teórico que afirma que el destino de todos los sistemas de adaptación complejos en la biosfera, desde las células hasta las economías, es evolucionar a un estado natural entre el orden y el caos, por lo que ambos polos son necesarios para alcanzar el equilibrio tras cada evolución puntual. En consecuencia, observando los problemas organizacionales e industriales existentes en la actualidad, es probable que al usar modelos desarrollados para la evolución sea posible encontrar señales de éxito empresarial. Por lo tanto y como veremos más adelante, nuestra conclusión es que podemos tratar a las organizaciones como a Sistemas Adaptativos Complejos, cuyos componentes estarán parcialmente conectados a través de una cultura común de prácticas de recursos humanos y de colaboración entre componentes y/o departamentos. Esto significará que cada vez que se realice un cambio en uno de los componentes, éste ocasionará un efecto en cascada y todas las demás partes del sistema se verán afectadas. Por ello, los gestores deberán ser conscientes del grado del impacto de cada actuación, ya que los cambios pueden crear estados de desequilibrio en la organización.

3.3 Entendiendo la Complejidad: La Matriz de Stacey

Sin embargo, ¿por qué hasta ahora las empresas han evolucionado y sobrevivido perfectamente sin agilidad? Como vamos a ver, podemos medir el grado de complejidad de los retos a los que se enfrenta un sistema. Ralph Douglas Stacey diseñó una matriz a modo de mapa visual con objeto de entender los caminos y conceptos de los sistemas complejos ante estos retos. El grado de complejidad de un sistema es algo difícil de medir e interpretar y, aunque existen diversos esquemas matemáticos que intentan modelar en profundidad la complejidad, pensamos que esta matriz es una herramienta pragmática y en cierto modo subjetiva, para abordar la categorización de sistemas en el día a día de un gestor realista. Luego podremos analizar para qué situación es mejor aplicar una aproximación Agile, iterando soluciones que se adapten a la situación conocida, o una aproximación tradicional, basada en planes estratégicos cerrados y bien analizados.

La problemática es difícil, como difícil es también decidir sobre la política más adecuada para la gestión en cada uno de los casos que se nos pueden presentar. No obstante, el horizonte se clarifica bastante si se dispone de un patrón de análisis que al menos permita ubicar al sistema en alguna de las cinco áreas definidas por Stacey, las cuales se clasifican dependiendo del consenso o acuerdo sobre el alcance del problema o solución buscada, y de la certidumbre sobre la adecuación de una solución técnica. Y así, si sabemos dónde está el sistema dentro de las áreas, también sabremos dónde estamos nosotros y qué acciones deberemos efectuar para gestionarlo adecuadamente.

El trazado original de la Matriz de Stacey es el siguiente:

Matriz de Stacey Simplificada

Fuente: Ralph Douglas Stacey

Stacey identifica cinco áreas de complejidad, en función de su etiología:

Área 1 – Sistemas Simples

• “Cerca del acuerdo y cerca de la certeza”.

• Toma de decisiones técnicamente racionales y control mediante monitorización.

En esta área es posible recopilar datos de experiencias pasadas y utilizarlos para efectuar estimaciones lineales o predicciones futuras.

Los Sistemas de esta área tienen muchos datos técnicos que permiten especificar y programar con precisión los proyectos antes de empezar a trabajar en las entregas, cuyo ciclo de vida se controla mediante la supervisión de planes muy detallados.

El dominio de lo simple es aquel en el que existe certeza sobre lo que se espera y un alto nivel de acuerdo sobre lo que va a ocurrir. El enfoque es el de Percibir, Categorizar y Responder, esto es, ver qué viene, dividirlo de acuerdo con las reglas establecidas y situarlo donde se espera.

Conclusión parcial para nuestro estudio: Aplican las metodologías clásicas.

Gestión en el Dominio de lo Simple. Características:

• Patrones repetitivos y eventos consistentes. Los patrones se repiten una y otra vez como parte del trabajo diario. Establecer claramente una relación causa/efecto es una condición necesaria para saber con certeza que nos encontramos en este dominio.

• Causalidad clara. La acción que realizamos tiene un efecto claro en el resultado y si cambiamos la acción obtendremos otro resultado distinto.

• Conocimiento de lo que se necesita. Toda la información necesaria para tomar decisiones está clara desde el primer momento y sabemos todo lo necesario para nuestro trabajo, por lo que podremos aplicar patrones repetitivos que nos faciliten la consecución de un objetivo.

• Gestión basada en hechos: La manera de medir y gestionar en estos dominios es sencilla. Tras una jornada de trabajo podremos medir y establecer un modelo para saber cuál debería ser nuestra productividad a corto y medio plazo.

Gestión en el Dominio de lo Simple – Trabajo del Líder:

• Usar las mejores prácticas. Existen multitud de recetas para utilizar en entornos simples.

• No es necesaria una comunicación extensa para realizar tareas sencillas. Una vez dadas y entendidas las instrucciones, no es necesario promover una comunicación continua para saber cómo se está desarrollando el trabajo, pues ésta sólo sería necesaria en caso de que las características de la tarea cambiaran considerablemente.

• Establecer y optimizar protocolos. Los protocolos son verdaderamente útiles en entornos simples, ya que facilitan el trabajo y permiten maximizar la eficiencia y la productividad.

• Ordeno y mando es el estilo de gestión más oportuno en este caso. Como las condiciones no van a cambiar y las herramientas son suficientemente conocidas, no es necesario promover la proactividad o que el operario entienda cuál es su trabajo o para qué lo hace. Este sistema es la base del taylorismo, esto es, la separación entre los que piensan y los que hacen.

Área 2 y 3 – Sistemas Complicados

• “Lejos del acuerdo y cerca de la certeza”.

• Toma de decisiones y control en términos políticos. Compromiso. Negociación. Establecimiento de coaliciones dominantes.

Los proyectos que se desarrollan sobre los sistemas de esta área tienen muy claros los objetivos a cumplir y la forma de cumplirlos, pero tienen dificultades para determinar cuáles de ellos son de mayor valor. En este ámbito, las capacidades de negociar, alcanzar compromisos y desarrollar coaliciones son muy importantes, pues la toma de decisiones resulta ser más política que técnica.

• “Cerca del acuerdo y lejos de la certeza”

• Toma de decisiones juiciosas, control ideológico, incrementos lógicos.

Los proyectos sobre sistemas de esta área pueden tener un alto nivel de acuerdo en relación con los objetivos planteados, pero poca certeza sobre los vínculos causa-efecto que llevarán a ellos. Las relaciones entre productos, resultados y beneficios pueden caer en esta categoría si se plantean hipótesis acerca de cómo los productos conducirán a los beneficios. Así pues, se precisa un fuerte sentido de visión compartida entre las partes interesadas y un enfoque de planificación flexible y realista. El líder y la propiedad deben enfocarse con determinación hacia el estado futuro acordado para el sistema, a pesar de que las rutas específicas no estén completamente determinadas.

Conclusión parcial para nuestro estudio: Por lo general, aplican las metodologías clásicas junto con una gran capacidad de negociación en el área 2 y con racionalidad y buen juicio en el área 3.

En estos dos dominios, o existe un acuerdo claro sobre el objetivo a conseguir, o bien, existe un buen conocimiento de la tecnología. En ellos hay que utilizar estilos de gestión que estén enfocados a la acción directa y al apoyo de expertos que ayuden a controlar el trabajo mediante el uso de las métricas pertinentes. Son dominios muy habituales en los entornos de producción, pues en ellos existen una serie de variables complejas que se intentan minimizar y se miden con objeto de evitar interferencias.

El enfoque habitual en estos casos consiste en Percibir (ver lo que viene), Analizar (investigar usando conocimiento experto) y Responder (tomar una decisión con base en lo que conocemos).

Gestión en los Dominios de lo Complicado – Características:

• Podemos predecir sólo con base en lo que conocemos. Las tareas siguen siendo relativamente estables y predecibles. Podemos predecir que normalmente tendremos lo que esperamos, pero habrá ocasiones en las que esas predicciones no funcionarán.

• Gestión basada en hechos. Es la característica fundamental de estos dominios. Al aparecer nuevas variables tendremos que analizarlas y tenerlas en cuenta para poder continuar con la tarea, o ésta se detendrá. Si tenemos más objetos que antes no conocíamos, su aparición debe tenerse en cuenta para poder tomar medidas y adaptar el proceso.

• Los expertos ayudan a corregir las desviaciones. El apoyo de expertos es útil para entender las situaciones anómalas y tomar decisiones sobre lo que hay que hacer y cómo modificar los procesos para dar cabida a las nuevas variables.

Gestión en los Dominios de lo Complicado - Trabajo del Líder:

• El apoyo de expertos ayudará a entender lo que ocurre. La opinión de un experto resultará determinante a la hora de entender el porqué de la situación inesperada que se ha producido, y a decidir cuál es la mejor manera de actuar en consecuencia.

• Uso de métricas para mejorar el control. En estos dominios es necesario el uso de métricas, cuadros de mando y reportes para entender qué está pasando y cuáles son las acciones precisas para poner freno a las desviaciones y mejorar la productividad. Una vez analizados y entendidos los datos, éstos se comparan con los que se esperan para tener así un mayor control de la situación.

• Ordeno y mando. Al igual que en el caso anterior, este estilo de gestión es el que más se adapta a la situación, para mantener un control férreo sobre lo que ocurre y dividir el trabajo entre pensadores y ejecutores. No obstante, dotar a ciertas personas de capacidad de decisión ante la aparición de una situación no esperada es añadir potencial complejidad al sistema, puesto que cada trabajador podrá tomar una decisión distinta ante las mismas circunstancias.

Área 4 – Sistemas Complejos

• “Poco acuerdo y poca certeza. Según Stacey, esta es la auténtica zona de la complejidad”.

• Toma de decisiones no programable, según el Modelo de Cubo de Basura (Teoría de la Organización, James Gary March, Herbert Alexander Simon). Este modelo posee características como la racionalidad limitada, la incertidumbre, la falta de datos fiables, etc. En él participan diferentes personas y de forma aleatoria.

La problemática de los sistemas de esta área combina bajo nivel de acuerdo con bajo nivel de certeza, dando lugar a proyectos muy complejos de gestionar. Esto suele desencadenar malas prácticas en la toma de decisiones, cuando lo que realmente se necesita es un alto nivel de creatividad e innovación, así como liberarse de las limitaciones pasadas para idear nuevas soluciones. La clave aquí radica en la adaptabilidad y en la agilidad, no sólo para el líder, sino también para la propiedad, para el equipo y para todas las partes interesadas (stakeholders). En este caso son especialmente útiles los enfoques del tipo Ingeniería Concurrente o Pensamiento de Sistemas.

Conclusión parcial para nuestro estudio: No aplican las metodologías clásicas, se necesita un enfoque rupturista basado en Business Agility.

El dominio de lo complejo ocupa la parte central de la Matriz de Stacey, que es el área más amplia, y a la que las empresas modernas se ven empujadas. Si nos encontramos en él, desconocemos más de lo que conocemos y además no podremos controlar las variables.

El enfoque adecuado de gestión en este dominio es el de Probar, Percibir y Responder o, lo que es lo mismo, aplicar un sistema de control empírico, que nos permita evaluar soluciones conforme aprendemos acerca del sistema. Estas son las claves de Business Agility, esto es, entregar pequeños incrementos de valor, testearlos y actuar en consecuencia.

Gestión en el Dominio de lo Complejo – Características:

• Lo que desconocemos es mucho mayor que lo que conocemos, y además no sabemos qué y cuánto desconocemos.

• El sistema es más impredecible que predecible. En ocasiones pensamos que lo impredecible es predecible. Podemos predecir un pequeño rango de situaciones, pero las variables son generalmente tantas y tan desconocidas que es imposible tenerlas todas en cuenta, además de que esto puede ser tan costoso como el propio proyecto en sí mismo.

• Respuestas emergentes. En este dominio casi no sirven de nada las experiencias anteriores. Las respuestas emergentes son necesarias para poder responder a los variados interrogantes que se van planteando, por lo que hay que dar completa responsabilidad a la persona que produce dichas respuestas. Cuando esto no se hace, se cae en situaciones que llevan a comités, informes y reuniones interminables que provocan la progresiva paralización de la organización.

• Muchas ideas que compiten con otras. En este entorno, donde las entradas no son predecibles y las salidas no son claras, las ideas compiten y esto supone un caldo de cultivo perfecto para crear un clima de crispación y frustración personal. La clave es separarlas y delegarlas adecuadamente, y decidir si además se han de priorizar aplicando algún criterio en particular. En cualquier caso, las ideas serán necesarias para poder encontrar las mejores soluciones a los casos únicos que irán apareciendo.

Gestión en el Dominio de lo Complejo - Trabajo del líder:

• Crear entornos que inviten a la acción. En los entornos complejos el tiempo es oro, y a pesar de no poder predecir qué hacer, es necesario tomar acciones y ser proactivo ante situaciones difusas y poco claras. La habilidad del líder para crear un entorno donde las personas de la organización se sientan cómodas tomando decisiones y poniéndolas en marcha, es vital para el éxito en estos entornos.

• Ser Líderes Serviles (Liderazgo Servil, Servant Leadership). No hay nada más Agile que este tipo de liderazgo, que se basa en tener una actitud de servicio a los demás. Esta actitud es clave para conseguir resultados en este tipo de dominios. Los líderes deben proporcionar herramientas a aquellos que conviven con el problema y generan ideas sobre cómo resolverlo, para así optimizar los resultados. No se debe confundir este tipo de liderazgo con el puro servilismo, pues el Líder Servil otorga poder y motiva a sus seguidores, mientras que el servilismo sin liderazgo se limita a darles todo lo que necesiten de forma automática e irreflexiva.

• Generar ideas. Otro aspecto fundamental del líder en estos dominios es la generación de ideas que puedan servir de base a los seguidores para poner en marcha iniciativas, de cara a la resolución de las situaciones complejas. La adopción de dichas ideas quedaría ya al arbitrio de los miembros del equipo, en función del contexto y de los antecedentes, esto es, no sería obligatorio seguir todas las ideas generadas por el líder.

Área 5 – El Caos.

• “Lejos del acuerdo y lejos de la certeza”.

• Desintegración y anarquía, escape masivo.

Allá donde no haya acuerdo ni certeza, prevalecerá la anarquía, el caos. En ocasiones, los individuos y las organizaciones suelen recurrir al escape, a la huida, pero esto no siempre es posible, pues estas situaciones no siempre se pueden evitar, por lo que es preciso disponer de estrategias para abordarlas en caso de que ocurran, que no estén basadas sistemáticamente en arriar los botes de salvamento. El límite entre esta área y el área de complejidad se denomina “el borde del caos".

Conclusión parcial para nuestro estudio: No aplica ninguna metodología de gestión, ni las clásicas ni las ágiles. Lo único que cabe plantearse en esta área es disponer de planes de emergencia que permitan reconducir la situación rápidamente, para hacer que el sistema caiga en cualquiera de las otras cuatro áreas. Si esto no se consigue, el éxito del proyecto dependerá exclusivamente del factor suerte.

En este dominio el estilo de gestión debe ser directo y enfocado a reducir el coste de la situación. En estos casos no aplica el uso de metodologías Ágiles y se requieren otras técnicas, como descomponer el problema en elementos finitos, enfocarse en un solo elemento de valor, o bien, en un pequeño grupo de elementos. El objetivo principal es sacar el sistema cuanto antes del Dominio del Caos para llevarlo a él o a sus componentes a cualquiera de los otros dominios de la Matriz de Stacey, para allí aplicar las técnicas o metodologías indicadas en los apartados anteriores.

El caos es una situación en la que es incierto tanto lo que se espera como las herramientas de gestión disponibles. El enfoque de gestión más adecuado en estos casos es Actuar (para intentar cambiar el sistema de dominio), Percibir y Responder. La idea es estabilizar cuanto antes la situación, ver los resultados instantáneos de nuestras actuaciones y luego intentar ser proactivo. En estas situaciones las actuaciones deben ser rápidas, pero no desproporcionadas, pues los elementos del sistema suelen ser muy reactivos y el sistema completo corre el riesgo de colapsar.

Gestión en el Dominio del Caos – Características:

• Alta turbulencia. Las condiciones cambian rápidamente. Es típica de los casos de caos la incapacidad para entregar valor o la generación de una gran cantidad de fallos. En estos casos hay que tomar medidas drásticas e intentar poner en orden la situación lo antes posible.

• No hay causalidad clara. Es imposible predecir los resultados de las acciones coyunturales que efectuemos. La confusión habitual entre una acción y su reacción viene dada por la intervención de variables espurias que no tienen nada que ver con las actuaciones efectuadas.

• Existen elementos desconocidos que afectan al sistema, y no hay forma de averiguar cuáles son ni de determinar de qué forma lo hacen.

• Se toman muchas decisiones sin el tiempo suficiente. El tiempo se vuelve en contra cuando hay que cumplir con objetivos y entregas arbitrarias, que no hacen sino añadir más restricciones al sistema en caos que intentamos entender.

Gestión en el Dominio del Caos - Trabajo del líder:

• Decisiones inmediatas para restablecer el orden. Los líderes deben tomar las riendas y adoptar cuantas decisiones sean necesarias para reducir la complejidad del sistema y así establecer un orden, aunque sea precario, que permita tomar otro tipo de medidas más normalizadas o regulares.

• Priorizar y seleccionar acciones de trabajo. Dejando a un lado el ordeno y mando, el líder debe decidir qué hacer y priorizar las acciones a tomar, teniendo en cuenta las opiniones y aportaciones del equipo que le parezcan válidas, según su criterio.

• Buscar lo que funcione sin perseguir la perfección. En este dominio, la única acción buena es la acción hecha, sin intentar llegar a la perfección y sin siquiera intentar de paso mejorar el proceso.

Por tanto, la matriz de Stacey, con sus dos ejes de certeza en tecnología y acuerdo en requisitos o alcance, añade ortodoxia a las decisiones sobre qué marcos metodológicos aplicar. Se suele añadir un tercer eje al modelo (aunque precisamente este detalle no es original de Stacey), que representa la “cantidad de personas involucradas en los proyectos”. Es un hecho que la complejidad de gestión de un proyecto o de un sistema crece en función del número de personas que trabajan en él (una tarea que es simple para una persona puede llegar a ser muy compleja para un grupo, si no se gestiona adecuadamente).

Resumen de los Enfoques de Gestión

3.4 Teoría de la Auto-Organización

Como comentábamos al inicio del capítulo, CT es en realidad un conjunto de teorías, pudiendo sacar distinto provecho de cada una de ellas. Veremos en el capítulo de Self-Determination Theory, o teoría de la auto-determinación, la importancia de poder dotar a los equipos Agile de autonomía en su gestión. En la teoría de la auto-organicación buscaremos claves para la gestión de un sistema complejo en el que las partes tengan dicha autonomía. Esta teoría dice que:

• Los sistemas complejos están compuestos por múltiples partes sin un control central fuerte.

• Las nuevas organizaciones emergen del conjunto debido a las interacciones de las partes.

• Las nuevas organizaciones también interaccionan haciendo emerger organizaciones más complejas.

• Por tanto, el sistema complejo está compuesto por distintas partes en diferentes escalas.

• Como todo está interrelacionado y las partes actúan debido a su relación con el entorno, no podemos analizar una parte por separado.

Conclusión parcial para nuestro estudio:

Tomar decisiones que apliquen a las partes desde una posición global, desde la alta dirección y como se intenta en una empresa jerárquica tradicional, nos sitúa en desventaja respecto a las pequeñas startups. De algún modo, necesitamos que las virtudes de la empresa surjan, emerjan, desde abajo, aplicando modelos empíricos autodirigidos por las partes, para encontrar el mayor valor que podamos aportar al cliente. El modelo de la Agile Corporation tal y como lo concebimos está fuertemente inspirado en esta teoría. Veremos concretamente en la capa de escalado cómo se construye la empresa compleja permitiendo la autonomía de los equipos de base, pero alineando el conjunto con los intereses de la empresa, y funcionando como un único sistema complejo adaptativo.

3.5 Teoría de Redes

Este escalado al que nos acabamos de referir, alineando las partes autónomas para perseguir un propósito común, genera una necesidad de mecanismo de comunicación y/o coordinación especial. Hablamos de construir la inteligencia del sistema complejo global, la empresa, a partir de las inteligencias individuales de las partes. En realidad, la inteligencia global será mucho mayor que la suma de las partes, si lo hacemos bien. Para ello, la Teoría de Redes (Network Theory) nos proporciona una forma de representar y analizar la inteligencia de nuestro sistema. Esta teoría se basa en la representación y el estudio de un sistema usando la topología y las reglas de las redes. Promulga que las características de las relaciones entre las partes tienen gran importancia para entender el sistema, y que la posición de cada parte en la red y su conectividad con el entorno importan. Asimismo, la conectividad dentro de un sistema puede crecer también, incluso exponencialmente (esto se verá más adelante en la Teoría del Caos).

La red es importante para la comunicación y la inteligencia de negocio. A esta Inteligencia de Negocio (Business Intelligence) ya no la veremos sólo como datos disponibles en un sistema de información, sino como el conocimiento emergente de la red de comunicación entre partes inteligentes. Pero la existencia de muchas relaciones entre las partes del sistema hace que los cambios en una de ellas puedan tener muchos efectos secundarios en el resto. Puede ocurrir que las partes afectadas por los cambios, que serán muchas, opongan resistencia a dichos cambios, es decir, que el sistema sea menos ágil y más rígido. Pero también puede ocurrir que estos cambios afecten en modo efecto mariposa a las partes y provoquen un gran cambio en ellas, como veremos más adelante al estudiar el “Efecto en Cascada”.

Conclusión parcial para nuestro estudio: La teoría de redes nos advierte de la importancia de las relaciones entre las partes del sistema, tanto para entender su funcionamiento, como para gestionarlo. Podremos fomentar la generación de relaciones, que como poco hará aumentar la inteligencia del sistema, la propagación de cambios deseados y el alineamiento de las partes, pero quizás también disminuya su agilidad. Todo esto será analizado y presentado en el capítulo dedicado al gobierno.

3.6 Teoría de Juegos

En muchas ocasiones vemos la cultura de una organización como la mayor barrera para mejorar en agilidad. En ocasiones lo usamos casi como excusa para justificar el fracaso después algún tímido intento de cambiar el modelo. En realidad, esto podría generalizarse y considerarse una reacción esperada ante cualquier tipo de cambio, ya sea hacia la agilidad o hacia cualquier otra cosa. Los individuos forman la cultura, entre otras cosas porque o se adaptan o quedarán en desventaja competitiva frente a aquellos que sí lo hacen. Por lo tanto, es normal que exista una reacción contraria al cambio establecido. Ya veremos que el sistema modela la cultura. Al mismo tiempo, los individuos que conforman el sistema intentan modularlo en su propio beneficio. Por ello, si intentamos cambiarlo con nuevas reglas o procedimientos, es decir, sacar a dichos individuos de su zona de confort, éstos intentarán rebelarse oponiéndose a las nuevas reglas o procedimientos.

Una forma de asegurar que los cambios tienen efecto, en el sentido programado, es hacer que los individuos reciban estímulos para esforzarse en buscar su adaptación al cambio, en lugar de gastar energía oponiéndose a los mismos (“trabaja con él, no contra él”). En este sentido, la Teoría de Juegos (Game Theory) nos es de mucha utilidad, ya que es una rama de la Economía que estudia las decisiones que debe tomar un individuo para tener éxito en una situación, teniendo en cuenta las decisiones tomadas por el resto de los individuos que intervienen en la misma situación. La Teoría de Juegos consta de una variedad de modelos matemáticos de bastante sofisticación y no se utiliza exclusivamente en Economía, sino también en gestión, estrategia, Psicología, Biología, etc. En nuestro caso será muy útil para promover patrones de comportamiento favorables para nuestros intereses, que emerjan en el conjunto de la organización. Es, aunque quizás no lo parezca, una forma de implementar mecanismos de hacer las cosas buscando el interés personal del individuo, y dañando lo menos posible la agilidad del sistema.

Para hacerlo, tengamos en cuenta que el individuo en cuestión no tiene que plantearse simplemente qué va a hacer para afrontar el problema, sino que también debe tener en cuenta lo que piensa que harán los demás individuos, además teniendo en cuenta que ellos también actuarán según crean que van a ser las actuaciones del primer individuo, por lo que al final todo está fuertemente acoplado. Crear mecánicas de motivación basadas en gamificación será de mucha utilidad.

La teoría de juegos comienza en el siglo XIX con el matemático francés Antoine Augustin Cournot, que estudió un duopolio en el que se alcanzaba poco a poco el nivel de precios y producción adecuados (en Economía, a esto se le denomina actualmente Equilibrio de Nash). Sin embargo, esta teoría experimentó un importante crecimiento y se formalizó por primera vez a partir de los trabajos de John von Neumann (Arquitectura de Programa Almacenado, ordenador ENIAC, Proyecto Manhattan) a mediados del siglo XX, debido a su potencial aplicación a la estrategia militar. Para entender el Equilibrio de Nash supongamos que está teniendo lugar una partida de un juego en la que participan dos o más jugadores que conocen su situación y la de todos los demás. En estas circunstancias, dicho equilibrio se alcanza cuando todos los jugadores han tomado ya una decisión y no pueden cambiarla sin empeorar su propia condición de equilibrio o bienestar. Este equilibrio se suele utilizar para regular situaciones de competencia entre empresas y para diseñar subastas de adjudicaciones públicas, pero igualmente podemos usarlo internamente entre individuos o equipos, siempre que esta competencia sea paralela y compatible con la colaboración entre dichos individuos y equipos, en la persecución de un propósito común alineado con los intereses de la propiedad. Son, como puede verse, mecanismos alternativos al ordeno y mando común en la empresa jerárquica que, aunque podría verse como un modelo más sencillo y directo, está demostrado que en un entorno de trabajo conceptual y creativo es menos efectivo, y además coarta la agilidad y capacidad de adaptación de los equipos. Veremos ejemplos con más detalle en el capítulo de gobierno.

Conclusión parcial para nuestro estudio: La teoría de juegos estudia el abanico de decisiones que debe tomar un individuo para alcanzar el éxito en determinadas circunstancias, teniendo en cuenta los múltiples rangos de decisión del resto de individuos que comparten las mismas circunstancias. En este escenario la complejidad radica en el fuerte acoplamiento de las decisiones de todos los individuos participantes, por lo que, si se tiene en cuenta esta cuestión desde un primer momento, se conseguirá desbloquear la situación y ganar en agilidad mientras se gana alineamiento con los intereses del accionista.

3.7 Teoría del Caos y Sistemas No Lineales

Y así llegamos a unas de las teorías de la complejidad que más esperanza aportan a la gran corporación. Si bien antes comentábamos la justificación de la reacción negativa al cambio por culpa de la cultura, ahora nos centraremos en la dificultad de cambiar una organización que tiene la inercia de un transatlántico o la torpeza de un elefante. Gracias a la teoría del caos tendremos la esperanza de que la cultura de una gran corporación pueda cambiar en poco tiempo, y por tanto adquiera rápidamente la capacidad de adaptación que necesita.

Más que una teoría, la denominada Teoría del Caos es en realidad un paradigma que supuso en su momento una revolución científica al reflejar que muchos modelos considerados hasta el momento deterministas y previsibles tenían severos límites en dicha previsibilidad, es decir, que su utilidad no era tanta como se suponía a la hora de predecir eventos futuros. Este detalle es de suma importancia, pues uno de los pilares de la ciencia es precisamente su capacidad de eliminar incertidumbre acerca de lo que ocurrirá en el futuro (por supuesto, dejando a un lado momentáneamente en nuestro análisis a la Mecánica Cuántica, que considera la incertidumbre como una de sus piedras angulares).

Esta teoría se enfocó desde el principio en el estudio de los Sistemas No Lineales, es decir, aquellos sistemas cuya respuesta no se acopla de forma lineal con los estímulos externos, o bien, en términos matemáticos, aquellos sistemas cuyo comportamiento no se puede modelar con base en la adición de los comportamientos independientes de sus componentes. Obviamente, ese es el caso de una corporación.

Fue iniciada por Henri Poincaré y popularizada gracias al trabajo del matemático y meteorólogo Edward Lorenz, y se ha utilizado en especial en campos como las matemáticas y la meteorología para explicar la inexactitud y la dificultad para obtener resultados previsibles derivados de la realidad. Ahora la aplicaremos en nuestro modelo, aunque más como una demostración de viabilidad del cambio y de la innovación en las organizaciones, que como una fuente de inspiración para la obtención de modelos útiles.

Un componente central de la Teoría del Caos es el reconocimiento de que el cambio dentro de los sistemas no es lineal (es errático, impredecible, inestable) y que se basa en las relaciones en evolución y en las interacciones complejas de los componentes, siempre cambiantes dentro del sistema. Estos factores hacen que los resultados sean prácticamente imposibles de predecir. Pero cuando esto se reconoce y se comprende su naturaleza no determinista, ello también permite una nueva flexibilidad de enfoque que puede brindar la libertad de innovar. De alguna forma es la demostración de que mediante un proceso creativo ortodoxo y determinado, surge la innovación en forma de productos e iniciativas de mejora impredecibles a priori.

La teoría nos dice que:

• 1+1 no tiene por qué ser igual a 2. Puede ser más o menos de dos. Todo depende de cómo estén relacionados los sumandos. Por ejemplo, dos personas que trabajan en equipo, combinando su conocimiento, pueden ser más eficaces que cualquiera de ellas por separado, o no serlo, dependiendo de cómo se organicen y cómo se lleven entre ellas.

• El sistema complejo siempre busca una situación de equilibrio. Sin embargo, los cambios en el entorno rompen este equilibrio constantemente, con lo que el sistema está siempre buscando una nueva situación de equilibrio.

• Un estímulo pequeño puede tener una reacción aumentada en la parte que lo recibe. La retroalimentación de los estímulos entre las partes puede producir una evolución exponencial denominada efecto en cascada (efecto mariposa). Estos períodos de gran cambio se denominan Phase Transition, pues con un cambio inicial pequeño se produce un gran cambio (sensibilidad a una condición inicial).

Es importante tener en cuenta que, a pesar de las apariencias, el caos al que se refiere esta teoría no implica una falta de orden generalizada, sino que los hechos y la realidad no se ajustan a un modelo lineal. Sin embargo, lo caótico no puede ir más allá de ciertos límites. Dicho de otra forma, las posibilidades son múltiples pero los resultados son limitados, no son infinitos, y existen predisposiciones a que los fenómenos se sucedan de determinada manera, predisposiciones conocidas como atractores.

La teoría del caos nos dice que existe la posibilidad de que se produzcan cambios grandes y rápidos en sistemas muy complejos, aunque también nos señala la dificultad de gobernar dichos cambios. Buscando un efecto mariposa podemos hacer que una empresa grande y compleja, cuyas partes tienden siempre al equilibrio, pueda cambiar en poco tiempo. Es decir, que hay esperanza para que las grandes corporaciones ahora inadaptadas puedan adoptar Business Agility, teniendo en cuenta lo siguiente:

• Es mucho más importante para los gestores reconocer los patrones organizacionales emergentes y las tendencias comerciales y ajustar la estrategia de la compañía en consecuencia, que estar directamente involucrados en el manejo de los detalles diarios del negocio.

• Los gestores deben desarrollar su sabiduría y acumular experiencia para saber cuándo y cómo superar los límites del orden sin cruzar el límite hacia el caos, el borde del caos.

• La visión, el liderazgo, los valores corporativos y la comunicación abierta son fundamentales para lograr los objetivos de la empresa, dada la complejidad en la gestión de una empresa en el entorno empresarial moderno.

Pero puede haber una gran cantidad de variables internas y externas al grupo humano que constituye la empresa, que pueden afectar a su funcionamiento y al mantenimiento de sus condiciones de viabilidad. Veamos algunos ejemplos:

• El nivel de producción de un empleado puede verse afectado por sus circunstancias personales.

• Los clientes y/o proveedores de la empresa pueden retrasarse en sus pagos y envíos.

• Otra empresa puede intentar adquirir la compañía o atraer a sus trabajadores.

• Puede haber un incendio que destruya una parte o la totalidad del trabajo realizado.

• Puede aumentar o disminuir la popularidad de la empresa por factores como la novedad de otras compañías con otro estilo, o la aparición de alternativas mejores.

En cualquier caso, el hecho de que la realidad sea múltiple y caótica no implica que sea desordenada. La Teoría del Caos nos enseña que la ciencia en general debe ser adaptable y no determinista, teniendo siempre en cuenta que no es viable una previsión exacta y absoluta de todos los sucesos

De la misma manera que la teoría nos ayuda a entender los mecanismos que pueden mover a las organizaciones, también podemos aplicarla a la complejidad del individuo. Al igual que hemos analizado el caso particular de la empresa y su imprescindible necesidad de adaptarse a los cambios para permanecer operativa y ser viable, podemos aplicar la teoría a cada individuo que forma parte de ese sistema complejo, el cual también debe cambiar y adaptarse para poder sobrevivir.

Inicialmente, la teoría del caos se ideó para explicar la existencia de divergencias en los resultados de la aplicación de algunos modelos matemáticos, meteorológicos o astronómicos. Sin embargo, esta teoría es aplicable a una gran variedad de disciplinas, incluyendo las vinculadas a las ciencias de la salud y las ciencias sociales. Una de las disciplinas en las que su aplicación tiene utilidad es la Psicología, sobre todo en lo relativo al estudio, el análisis y la interpretación de la motivación, lo cual puede llegar a ser relevante en el ámbito de Business Agility, como veremos cuando estudiemos la Self-Determination Theory en el siguiente capítulo.

La Teoría del Caos, como paradigma que propugna que pequeños cambios en las condiciones iniciales pueden generar una gran diversidad de los resultados asociados, puede ayudar a explicar la gran variedad de actitudes, puntos de vista, pensamientos, creencias o emociones, como reacción ante unas determinadas circunstancias.

Si bien y por norma general la mayoría de las personas buscan sobrevivir y realizarse de diferentes formas, existe una amplia variedad de circunstancias que transforman su conducta y pensamiento, y moldean su modo de vivir la vida. Por ejemplo, vivir una vida relativamente feliz y tranquila no asegura que una persona no desarrolle un trastorno mental, al igual que sufrir un trauma severo puede no producir trastornos posteriores.

Así pues, la Teoría del Caos puede ser útil de cara a intentar explicar por qué algunas personas pueden desarrollar fortalezas o problemas mentales y otras no. También puede explicar por qué determinados tratamientos no resultan eficaces en determinadas personas, aun cuando en la mayoría de la gente resultan efectivos. O por qué dos personas con los mismos genes y las mismas experiencias vitales no reaccionan de igual manera ante un estímulo o evento concreto. Detrás de esto puede haber diferencias de personalidad, capacidad cognitiva, focalización de la atención en aspectos concretos, situación emocional y motivacional en un momento dado, u otros múltiples factores. Asimismo, algunos procesos psicológicos como la ansiedad podrían explicarse mediante la teoría del caos. Para muchas personas con ansiedad y trastornos asociados, el hecho de no saber qué puede suceder ante su actuación en un entorno determinado les ocasiona una profunda sensación de malestar, y con ella una posible actitud de eludir activamente aquello a lo que se teme. Dicho de otro modo, la incertidumbre que genera la dificultad para establecer predicciones fiables, debido a las múltiples posibilidades de una realidad caótica, despierta la sensación de preocupación. Ocurre lo mismo con trastornos como el obsesivo/compulsivo, en el que la incertidumbre de que pueda suceder algo temido debido a los pensamientos intrusivos, induce ansiedad y puede provocar el uso de compulsiones como medida de protección temporal.

Dentro de la psicología y de esta teoría, genética y cultura podrían ser considerados como atractores, al producir una cierta tendencia a comportarse de determinada manera. Pero esto no implica que todos nos comportemos igual ni tengamos las mismas formas de pensar. Los patrones comportamentales y los hábitos también son atractores, lo cual puede explicar por qué en algunos casos de trastornos mentales hay recaídas recurrentes.

Efecto en Cascada o Efecto Mariposa

La no linealidad, la alta reactividad de sus componentes y la abundancia de interrelaciones complejas entre los componentes de un sistema caótico, hacen que éste suela responder de forma inesperada ante los estímulos externos, produciéndose por lo general reacciones desproporcionadas y deslocalizadas en relación con el estímulo causante. Esto se denomina Efecto en Cascada o Efecto Mariposa. Esta denominación procede, al parecer, de un antiguo proverbio chino que rezaba: “el aleteo de una mariposa se puede sentir al otro lado del mundo”. El significado original de este proverbio aludía simplemente al hecho de que, en el fondo, todo está conectado, pero no contemplaba el hecho no menos cierto de que el efecto de este aleteo podía ser desmesurado en relación con la levedad de su causa.

Ya en el ámbito de la Teoría del Caos, este efecto se puede sustanciar en el hecho de que los sistemas complejos poseen una elevada sensibilidad en lo relativo a ciertas variables, cuya alteración puede provocar un efecto dominó o una reacción en cadena que progrese geométricamente hasta producir un resultado de gran magnitud y fuera de lo esperado. Esto sabemos que puede ocurrir en cualquier organización, sea o no Agile. Los incendios originados por un email malinterpretado o una nueva medida de control mal meditada son constantes en las empresas. La cuestión es entender que el estímulo de una acción introducida en el sistema, junto con la retroalimentación de su resultado como estímulo adicional al propio individuo o los que le rodean, son un mecanismo poderoso, aunque sensible, para propiciar grandes cambios.

Conclusión práctica para nuestro estudio. Por una parte, vivir en el caos es irremediable, pero debemos encontrar mecanismos para gestionarlo. Es razonable pensar que, a mayor agilidad mayor libertad de adaptación de las partes y mayor caos, pero ha debido quedar claro que eso es una característica del sistema, y no necesariamente una limitación. En cualquier caso, la Teoría del Caos es fundamental a la hora de planificar cambios de patrones, como veremos más en detalle en el Capítulo 10 (Gobierno del Modelo).

En síntesis, la teoría del caos establece que, en ocasiones, pequeños cambios en las condiciones iniciales crean diferencias notables respecto al resultado final esperado, con lo que una gran mayoría de sucesos y sistemas no resultan totalmente predecibles. No obstante, en términos positivos y en otro orden de cosas, la conclusión principal es que hay formas de generar grandes cambios con poco esfuerzo.

3.8 Sistemas Complejos Adaptativos

Resulta evidente que, ante un entorno cambiante, necesitamos una empresa capaz de adaptarse a dichos cambios, pues ésta es su única forma de sobrevivir. En este contexto, adaptación implica capacidad de innovación, identificación rápida de amenazas y oportunidades, pronta respuesta a movimientos de la competencia, ductilidad ante los cambios y, en general, agilidad en garantizar los intereses de la propiedad maximizando en todo momento la aportación de valor al cliente.

Asumiendo que la empresa es un sistema complejo, podemos asegurar dicha adaptación dirigiéndola de una forma orquestada desde la alta dirección, planificando y controlando los cambios. Es obvio que parte del mandato de adaptarse al entorno debe ser delegado a los directivos medios, que tomarán decisiones con mejor conocimiento sobre su entorno próximo y éstos delegarán, a su vez, en sus equipos, que analizarán y tomarán micro-decisiones relativas a su ámbito.

Es fácil imaginar que una directriz muy férrea y planificada al máximo nivel por parte de la alta dirección, asegurará el alineamiento con las decisiones de la propiedad, pero conllevará errores propios del desconocimiento del detalle que aplica a cada ámbito de la empresa. Por otra parte, una delegación total del mando directamente a los equipos operativos provocará una situación de caos y difícilmente alineada con los intereses de la propiedad. Como ocurre en muchos casos, en el medio estará la virtud, pero dentro de la escala de grises entre una jerarquía férrea y una delegación plena hay muchas opciones y la forma en la que diseñemos nuestro sistema, nuestra empresa, va a determinar que el alineamiento esté más o menos asegurado, proporcionando más o menos delegación en la toma de decisiones para la adaptación.

En este sentido, Yuval Noah Harari en su libro Sapiens apunta que los homo sapiens estaban adaptados a grupos pequeños. Cuando estos grupos crecían demasiado, el orden social se desestabilizaba y provocaba su división en bandas más pequeñas. Aunque un valle pudiera alimentar a 500 personas, era imposible que tantos extraños pudieran convivir, que pudieran decidir sobre quien iba a ser el líder, o cómo organizarse para la caza. Del mismo modo, Harari comenta que la investigación sociológica ha demostrado que el máximo tamaño natural de un grupo basado en las relaciones personales es de unos 150 individuos, ya que esta es la cantidad máxima de personas que alguien puede conocer de forma íntima. Con grupos por encima de ese número, se requiere un alineamiento global basado en cierto tipo de relaciones para mantener el orden. Pero estas relaciones no tienen por qué ser únicamente las basadas en la jerarquía de un jefe que manda sobre una tribu, o las de un rey que manda sobre el pueblo, aunque estas relaciones fueran las más básicas y entendidas en un principio. Una sociedad puede estar basada en diferentes poderes separados sin ser ninguno de ellos absoluto, en reglas de convivencia consensuadas, en cooperaciones para generación de sinergias y en controles aceptados, algo más parecido a los modelos de democracia que han demostrado mayor capacidad de adaptación en el plano político, mayor progreso y mejor supervivencia que las estructuras jerárquicas alineadas con un dictador, un jefe de la tribu o un rey. En definitiva, los líderes de tribu han demostrado aportar más valor que los jefes de tribu y la teoría de los Sistemas Complejos Adaptativos o CAS (Complex Adaptive Systems) nos da pistas de por qué siendo necesario un orden global, la autonomía de las partes favorece la adaptación y la supervivencia.

Para definir estos sistemas de una forma muy breve, diremos que son sistemas autónomos y que ante alteraciones en el entorno buscan puntos de equilibrio a través de la adaptación ambiental y la auto-organización, haciéndolo no de una forma planificada y predeterminada desde exterior, sino que el control y el orden resultantes son reacciones emergentes.

En este sentido, la Teoría de los Sistemas Complejos Adaptativos establece que:

• El sistema evoluciona mediante su adaptación al medio como mecanismo de supervivencia.

• La adaptación está basada en cooperación y competencia entre los agentes para subsistir adaptándose al cambio (Game Theory, como hemos visto anteriormente).

• En este proceso no hay una coordinación top-down.

• Las partes del sistema están dotadas de autonomía para adaptarse según su entorno y siguiendo un conjunto de reglas de comportamiento.

• Los patrones de adaptación surgen bottom-up.

• La reacción del conjunto emerge de la autonomía de las partes.

• Si no existe coordinación central, el sistema se adapta mediante evolución por competición y cooperación.

La Teoría de los Sistemas Complejos también establece que, si un sistema complejo no funciona de esta manera, tampoco tendrá la agilidad suficiente para adaptarse y competir con el entorno.

Conclusión parcial para nuestro estudio: La empresa productiva del mañana debe tratarse como un sistema complejo en el que la ventaja competitiva emerja de un alto grado de autonomía de las partes. Un sistema jerárquico es competitivo sólo para situaciones sencillas y estables, allá donde la complejidad del problema sea baja, y donde podamos adoptar decisiones y planes detallados, y a nivel general. Un sistema complejo puede contener una combinación de diferentes modelos aplicados a cada una de sus partes, unos más jerárquicos y otros más autónomos, dependiendo de la naturaleza del entorno en el que opere cada parte.

Viniendo de una tradición de organizaciones jerárquicas, bien adaptadas a un entorno estable y sencillo, es normal dudar de la viabilidad de la adopción de modelos autónomos. Hasta ahora, esta autonomía sólo se percibía en la voluntad de delegar responsabilidad en los subordinados para que ellos, con más conocimiento del detalle, tomaran decisiones más acertadas. Veremos más adelante que hay soluciones que hacen viable dicha autonomía.

Composición de un Sistema Complejo Adaptativo

Los elementos básicos de un CAS son los agentes. Los agentes son entes semiautónomos que evolucionan para maximizar su encaje con el entorno. En el sistema de la empresa, dichos agentes son los individuos y las células de trabajo (o equipos), pero esto lo veremos más adelante.

Los agentes tienen esquemas, plantillas mentales que definen cómo interpretar la realidad y cómo responder a un estímulo. Es decir, estos agentes tienen lecciones aprendidas o esquemas de comportamiento, de forma que cuando reciben una motivación en forma de estímulo, aplican dichos esquemas para reaccionar de una forma determinada. Así pues, un esquema define la interacción de un agente con el resto, mientras que un estímulo llega desde su entorno, bien desde otros agentes o desde el exterior. La interacción entre agentes implica un intercambio de información y recursos.

Pero hasta este punto, aunque el sistema descrito funciona como un sistema complejo, todavía no demuestra capacidad de adaptación. Esto ocurre en realidad con la capacidad de los agentes para cambiar y hacer evolucionar los esquemas para su supervivencia, a través de un proceso de selección-promulgación-retención. Esto es, cuando un agente recibe un estímulo, lo observa y aplica un esquema. Viendo el resultado obtenido, el agente tiene la autonomía de decidir alterar el esquema para adaptarse mejor al estímulo la próxima vez. Así, el esquema muta, evoluciona o se combina para generar un nuevo esquema (adaptación/evolución). El cambio del esquema hace al agente más robusto, fiable y adaptable. Veremos todo esto desde una dimensión distinta en el próximo capítulo, Self-Determination Theory (SDT), cuando tratemos la motivación.

Conclusión parcial para nuestro estudio: Los agentes (los individuos y las células de las que se compone la empresa) deben tener agilidad para cambiar sus esquemas, su forma de afrontar los estímulos que les llegan, como mecanismo de aprendizaje. Sin embargo, para lograrlo deberán tener predisposición para ello, deberán ser receptivos al cambio.

Clasificación de Componentes de un CAS

Para el correcto análisis del sistema, las teorías de la complejidad proponen que los agentes tengan etiquetas que definan cómo se comportan y por tanto cómo interactuar con ellos. Volviendo a lo dicho anteriormente acerca de la limitación del hombre para conocer a más de 150 individuos, las etiquetas ayudarán al crecimiento del grupo ya que los agentes podrán actuar en base a la etiqueta del otro agente con el que necesiten interactuar y no por el conocimiento íntimo del mismo. Las etiquetas facilitarían además la formación de agregados o meta-agentes. Los meta-agentes ayudarían a distribuir funcionalidades, permitiendo así que la especialización y la diversidad prosperasen, posibilitando, la creación de organizaciones grandes donde reinara el orden en lugar del caos.

Conclusión parcial para nuestro estudio: No necesitamos tratar a todos los agentes (los individuos y las células) de la misma forma en un sistema complejo. Podremos etiquetarlos y/o clasificarlos, según sus maestrías, según su función, o según el subsistema en el que se encuadren.

Características Emergentes de un CAS

Hasta ahora, parecería que la empresa, como sistema complejo, fuera perfectamente predecible. La hemos descrito como un sistema que se adapta, pero que lo hace de forma programada, aunque esa programación esté delegada a sus partes que, si bien toman decisiones de forma autónoma, lo hacen dentro de un orden prefijado y dirigido por la propiedad. Pero la realidad es bien distinta. Como ya hemos dicho, del sistema complejo emergen características o propiedades que no tienen las partes por sí mismas. Cuando una propiedad de un sistema no puede asignarse a un único elemento, como ocurre cuando nos referimos a la acción de defensa de un equipo de futbol, el remolino en una masa de agua, la capacidad de exploración de un hormiguero, la colmena como mecanismo de subsistencia, etc., hablamos de una propiedad emergente del sistema. Esas propiedades surgen irremediablemente, para bien o para mal, y no siempre son fáciles de predecir.

Y es que, analizando individualmente las partes implicadas, si no tuviéramos idea previa sobre dichas propiedades, seríamos incapaces de deducirlas. Estudiando a una hormiga sería difícil predecir la longitud y la complejidad organizativa de un hormiguero. Del mismo modo, si elimináramos las partes, acabaríamos también con la propiedad emergente, del mismo modo que una hormiga no hace un hormiguero ni una molécula de agua hace un remolino. En resumidas cuentas, la propiedad emergente no es la suma de las propiedades de las partes, sino algo añadido y relativo al conjunto y todo esto es igualmente aplicable a la empresa. Analizando a un empleado, será difícil deducir la apetencia al riesgo de que dispone la empresa, su capacidad de innovación o su capacidad de adaptación al entorno y, del mismo modo, el valor que una empresa aporta a sus clientes y a sus propietarios es fruto de la combinación del comportamiento y acciones de sus individuos, pudiendo representar mucho más (o mucho menos) que la suma del valor aportado por cada individuo. En resumidas cuentas, la manifestación de la propiedad emergente afecta a su vez al comportamiento de los individuos que forman parte del sistema. Al igual que un remolino arrastra a partículas de la masa de agua que se situaban fuera, o una hormiga explora gracias a la interacción con sus cohabitantes del hormiguero, los empleados se ven también extra motivados, deprimidos, envalentonados, decididos o reprimidos por la cultura reinante en la empresa, que no es sino una propiedad emergente de dicho sistema.

Expresando esto en términos de la teoría de complejidad, una propiedad emergente la constituyen los patrones, que se extienden entre los agentes y los módulos, y que describen la evolución potencial del sistema. Son características que afectan al sistema de forma global o parcial.

Conclusión parcial para nuestro estudio: Los patrones emergentes son esenciales para establecer o cambiar la cultura de la empresa y para gobernar el alineamiento de sus partes. En la gestión del ACF, los patrones serán los comportamientos del día a día requeridos a nivel de empresa o de área organizativa, entre los que buscaremos aquellos que sean favorables, intentando evitar también aquellos que sean desfavorables.

Innovación en un CAS

Es incuestionable que, en un entorno competitivo la innovación es la clave para la supervivencia, ya hablemos de empresas o de cualquier otro tipo de sistema en la naturaleza. Los sistemas complejos se ven forzados a cambiar, a innovar, para adaptarse y conseguir una ventaja competitiva que les permita sobrevivir. De esta forma, la innovación en la naturaleza surge con los cambios. La mayoría de ellos simplemente agitan al sistema, que suele volver a su equilibrio tras los pertinentes reajustes y readaptaciones de las partes. Es decir, gran parte de la innovación queda en nada. Dicho de otro modo, los estímulos del exterior alteran el CAS, que transita siempre de forma natural hacia puntos de equilibrio mediante la adaptación al medio y la auto-organización. Si mediante el cambio se llega a un punto de equilibrio más inestable o desventajoso, el sistema desaparecerá. Si no llega a tener la fuerza de abandonar el punto de equilibrio actual, quedará como está. Si tiene la fortuna de mutar a un punto de equilibrio más competitivo, sobrevivirá, posiblemente a costa de otros. Podemos decir, por tanto, que el control y el orden en los CAS son características emergentes (naturales) en lugar de predeterminadas (planificados).

De esta forma, los investigadores han resuelto que la innovación y adaptación tienen lugar sobre todo en el borde del caos (Kaufmannn 1995), cuando el sistema deja de estar en equilibrio. La innovación no es una acción planificada, sino que al igual que el control y el orden, también es una característica emergente en el sistema, por lo que si llevamos este concepto a la empresa para que la innovación emerja en un equipo, sus gestores, líderes y miembros en general deberán cultivar activamente el conocimiento, la creatividad, la motivación, la diversidad y la personalidad en los trabajadores. No es, por tanto, una acción que pueda buscarse de forma directa, sino el resultado de defender en el equipo un conjunto de virtudes básicas (Jurgen Appelo, Management 3.0). Con dichas virtudes, que variarán según la situación del equipo, surgirán de forma espontánea las oportunidades de innovación.

Finalmente, debemos comprender que, al igual que el comportamiento de un individuo afecta al sistema y su acción influye nuevamente en el individuo, la introducción, adaptación o cambio de un sistema completo en un entorno, modifica invariablemente dicho entorno, lo cual implica en sí mismo un nuevo reto de adaptación, y de ahí la imposibilidad de planificar a largo plazo. Podemos decir que es aplicable el juicio de Antonio Machado: “Caminante no hay camino, se hace camino al andar”.

Sólo obtendremos innovación si el cambio es bienvenido, esto es, si en lugar de tratar de obviarlo o evitarlo, nuestros agentes buscan una adaptación a él que genere una ventaja competitiva frente a los otros sistemas con los que competimos. La innovación no se busca, se encuentra de forma natural cuando emerge de un sistema preparado para ella.

Hay varias propiedades que caracterizan a los sistemas complejos adaptativos: interdependencia, coevolución, no linealidad, imprevisibilidad, adaptabilidad y autoorganización.

Continuando con nuestra línea argumental, el sistema adaptativo complejo se considera adaptable por naturaleza, lo que significa que aprende de su propia experiencia y, por tanto, tiene la capacidad de adaptarse a condiciones nuevas e imprevistas. Las partes interdependientes del sistema actúan juntas y crearán algo nuevo al autoorganizarse, sin embargo, para que tenga lugar la autoorganización, se necesitará un estado inicial de inestabilidad, que a menudo se describe como el borde del caos (como hemos visto en la Matriz de Stacey). Mientras que algunos autores afirman que los sistemas adaptativos complejos no se pueden controlar de ninguna forma, otros, entre los que nos encontramos nosotros, proponemos algunos enfoques para su gestión, que comienzan disponiendo de una imagen compartida del futuro que la organización está buscando crear, es decir, una visión o propósito. Es esta visión compartida por el sistema en su conjunto la que posibilita su gestión, pero para ello el propósito tiene que integrarse en todas las partes del sistema y garantizar que se tomen todas las medidas necesarias para lograrla.

Es sabido que las reglas simples pueden dar lugar a comportamientos complejos, debido a la imprevisibilidad de los sistemas complejos, por lo que los gestores deberán liderar las organizaciones de manera simple, pero al mismo tiempo, percibiendo dicho gobierno como una experimentación que proporcionará resultados sobre los que se debe reflexionar, e incluso realizar cambios en caso de ser éstos necesarios. Los teóricos afirman que, si sólo aplicamos las reglas simples mencionadas, no todo tendrá por qué ser simple, sino más bien todo lo contrario. Mientras que en una forma tradicional de pensar las organizaciones buscaban la estabilidad para tener éxito, en la empresa del futuro los gestores deberán crear y mantener un ambiente de tensión e inestabilidad para fomentar la innovación.

Si bien los sistemas adaptativos complejos se pueden percibir como una metáfora útil para describir una nueva forma de ver las organizaciones, no se puede argumentar que el enfoque de los sistemas adaptativos complejos tenga todas las respuestas, sino que explica el hecho de que el cambio es posible y que se puede manejar a través de enfoques aprendidos del comportamiento de los sistemas en el entorno real.

3.9 Conclusiones Generales de la Teoría de la Complejidad para nuestro estudio

Como gestores, para dirigir la empresa en el entorno actual, tenemos dos opciones:

• La primera opción es dirigirla como un sistema complejo adaptativo esto es, como un ser vivo que evoluciona por sí mismo, y cuyas partes son inteligentes y autónomas para adaptarse y responder al cambio.

• La segunda opción es dirigirla como un sistema complicado (visto desde el punto de vista del que quiere gobernarla en detalle), como una máquina perfectamente diseñada para que desarrolle la estrategia preprogramada, sin pensar.

Evidentemente, ambos estilos de gestión aplicarán a la empresa en función del área de la Matriz de Stacey en la que podamos ubicarla, tras el pertinente análisis.

A nuestro entender, es evidente que el entorno empresarial se ha complicado y está a merced de grandes cambios en su ámbito: nuevas tecnologías, nuevos competidores, cambios en las expectativas y necesidades de sus clientes, así como cambios en las expectativas de sus empleados y un largo etcétera. Este escenario hace inviable la segunda opción en la mayoría de los casos.

CT es además la evidencia de que, en la actualidad, los modelos empresariales son válidos tan sólo para determinados casos. Por tanto, para cada empresa y cada situación es menester definir un modelo distinto, lo cual hace más interesante el trabajo del gestor. El ACF pretende facilitar esta labor mediante un marco de trabajo que ayude al gestor a encontrar el modelo específico que sirva para su sistema complejo, para su empresa.

La supervivencia del sistema complejo estriba en sus capacidades de Competencia y Adaptabilidad, de la forma siguiente:

• Competencia: El sistema se adapta al entorno para sobrevivir y, a su vez, con su adaptación hace cambiar al entorno poniendo en riesgo al resto de sistemas. Pero si un sistema complejo es incapaz de adaptarse y competir en un entorno cambiante, morirá. Además, sólo puede competir en un entorno complejo mediante delegación del propósito de supervivencia a las partes, o con innovación emergente del conjunto.

• Adaptabilidad: La adaptabilidad es una característica emergente de los sistemas complejos, basada en la autonomía de sus partes para afrontar el cambio, aprovechar las oportunidades y combatir las amenazas. Los sistemas complejos surgen y reinan ante los cambios en entornos complejos, compitiendo y/o cooperando con otros que terminarán muriendo si no tienen la misma capacidad de adaptación.

En su libro “Management 3.0”, Jurgen Appelo analiza esta diversidad de opciones y su validez para cada caso, proponiendo su panfleto para gestionar los proyectos complejos, basado en los siguientes principios:

• Cada problema tiene múltiples soluciones. No hay una mejor forma de gestionar los proyectos.

• Las soluciones (mejores prácticas) dependen del contexto del proyecto.

• Los cambios en el contexto requieren cambios en las soluciones. Cuando el entorno de los proyectos cambia, los proyectos cambian en consecuencia.

• Toda solución extraña es apropiada en algún caso. Siempre hay un momento y un lugar para las prácticas menos populares.

• Las soluciones impactan en el contexto al aplicarlas, y cambian la forma en que se las aplicará en el futuro.

• La Simplicidad requiere comprensión de la Complejidad. Debemos entender la complejidad antes de aplicar soluciones simples.

• La mejor solución no es predecible. Tenemos que probar diferentes prácticas para saber si funcionan en nuestro contexto.

Fuente: Jurgen Appelo

Y para finalizar este capítulo, concluimos que analizando las teorías de la complejidad encontramos esperanza para la resolución de problemas complejos, o esperanza en abordar propósitos ambiciosos a nivel corporación, aunque vemos que la solución no será añadir más planificación estratégica, más orquestación rígida y más controles para evitar desviaciones, sino gestionar los grandes equipos como agrupaciones de individuos o células autónomas aunque motivadas, para alcanzar un propósito común y así alinearse con la propiedad. En el próximo capítulo veremos cómo conseguir dicha motivación.

Por tanto, nuestra empresa no es una máquina perfectamente definida, con piezas perfectamente engrasadas y engranadas que funciona a capricho de su creador, más allá de indeseadas desviaciones que se buscan y corrigen con mano firme, sino un jardín que diseñamos como un conjunto de elementos, de muy distinto tipo como arbustos, árboles o estanques, todos ellos vivos y que evolucionan a su libre albedrío más allá de nuestras intervenciones y estímulos concretos en forma de poda, riego, trasplante, etc. Cada planta o arbusto crecerá adaptándose al entorno donde le ha tocado estar, haciendo todo lo mejor que pueda dentro de sus limitaciones, luchando por sobrevivir y prosperar, pero alineado con el diseño global del jardín que ha planificado su creador, cuya belleza y armonía emerge como una propiedad del conjunto, mucho más importante que la suma de las partes (si el creador ha hecho bien su trabajo).

A continuación, analizaremos la teoría de la auto-determinación que nos dará las claves necesarias para que todo esto funcione.

4 Self Determination Theory

“No hay cosa, por fácil que sea,

que no la haga difícil la mala gana”

Juan Luis Vives

4.1 Introducción a Self-Determination Theory (SDT)

Hoy en día, más que nunca, se habla de la depresión como de una enfermedad del espíritu, del alma, más que del cuerpo. La depresión es una profunda tristeza que arrebata a la persona la energía para efectuar cualquier trabajo, para desempeñar cualquier labor, para ejecutar cualquier encargo o para tomar cualquier resolución. Y la depresión no es sino la ausencia extrema de motivación. Quizá podría parecer que iniciar este capítulo de una forma tan abrupta pudiera ser algo extremista, pero no lo es en absoluto. Mucho se ha hablado de la motivación en la bibliografía psicológica y psiquiátrica, y mucho también acerca de los efectos de las personas tóxicas en las organizaciones. No son asuntos tópicos ni míticos, sino reales como la vida misma.

Podemos engañarnos pensando únicamente en el trasfondo del Emilio de Jean-Jacques Rousseau, y en la bondad natural que este ideólogo le presuponía a todo ser humano. Pero acto seguido debemos volver a la cruda realidad y para ello no hay nada mejor que leer La Vida es Sueño, de Pedro Calderón de la Barca, publicada más de cien años antes. Ambas obras capitales de la literatura universal presentan respectivamente los dos polos opuestos de la naturaleza humana o del temperamento humano, la bondad innata y la maldad innata, enfocando, no obstante, el problema del temperamento de dos formas similares. Rousseau elabora un tratado técnico de la ciencia didáctica, en el que sienta las bases del modelo educativo que supuestamente permitiría vivir y sobrevivir al ser bueno en un mundo caótico y corrupto. Calderón se centra menos en el modelo educativo y enfatiza la figura del pedagogo, del maestro, capaz de redirigir al ser malo, que tiene asignado un destino oscuro y supuestamente invariable, hacia la excelsa bondad mediante una adecuada y firme tutorización. Aunque un autor se centra en la pedagogía y el otro en el pedagogo, en realidad ambos enraízan su trabajo en el mito de la caverna de Platón: el ser humano vive en el mundo de los sueños, inmerso en la oscuridad de una caverna, y sólo saldrá de ella buscando el bien para llegar finalmente a la luz.

En cualquier caso, el mensaje de fondo enlaza con el tema que nos interesa: el hombre posee la libertad para estructurar su vida, sin dejarse arrastrar irremisiblemente por un futuro nefasto y supuestamente predefinido. Sin embargo, aunque según Aristóteles, el hombre es potencialmente libre de organizar su estilo de vida y sus acciones, no obstante, para ejercer esa libertad, para pasar al acto, necesita motivación.

La motivación es el combustible del ingenio y la sangre del alma. Cuántos proyectos humanos habrán fracasado en el pasado debido a un mal gestor o a un mal compañero, y no precisamente por gestionar mal o por no tener compañerismo, sino porque este tipo de personas tóxicas son especialistas en destruir la motivación colectiva de los equipos, y la motivación individual de las personas. Ahora bien, como se deduce de esta introducción metafísica y como estudiaremos en este capítulo, hay dos tipos de motivación: la intrínseca y la extrínseca.

Self-Determination Theory (SDT) es una teoría empírica sobre el comportamiento humano y el desarrollo de la personalidad. Se trata de un estudio extenso con seis ramas de investigación, a las que los autores llaman miniteorías. En este libro recogemos un resumen de las conclusiones de esta teoría, que nos servirán para sustentar el marco de trabajo del ACF (Agile Corporation Framework) y, como es natural, los autores no aspiramos a exponer en este libro la SDT con la extensión y el rigor que emplean sus autores originales.

En el capítulo anterior vimos que un sistema complejo adaptativo está formado por múltiples partes autónomas, aunque no independientes. Si hablamos de una empresa, estas partes son los individuos. Y es que lo más importante en una organización son las personas, aunque no podemos decir que sean el activo más importante, sencillamente porque no son un activo que pertenezca a la empresa. No podremos tratarlas como máquinas programadas, sino como colaboradores que trabajan a cambio de algo. Este mecanismo de recompensa, esta contrapartida, será la motivación para su colaboración con la empresa. Dicha motivación se compone de una parte extrínseca y otra intrínseca, como indicábamos en la introducción y, sea como sea el tipo de trabajo, lo que sí es cierto es que lo importante es la suma de ambas motivaciones y que la intrínseca, como veremos, no tiene por qué costar dinero a la empresa.

Entrando en describir cada una de ellas, la parte intrínseca de la motivación depende en gran medida del propio trabajador, pues impulsa a disfrutar de las tareas por el siempre hecho de hacerlas. Por otra parte, la parte extrínseca, que sí es más controlable de forma artificial por la empresa, es la compuesta por estímulos externos dirigidos a impulsar las tareas o comportamientos con factores que nada tienen que ver con el disfrute de la propia tarea, como pueden ser el salario, los premios, las recompensas, evitar castigos, etc. En cualquier caso, esta última no es la panacea, pues hay numerosas pruebas científicas de que parte de esta motivación no obtiene el efecto deseado cuando el trabajo a realizar es conceptual o creativo. El ideólogo Daniel Pink ha analizado este detalle en particular, plasmando en su obra que cuando el trabajo es de este tipo y se sobrepasa un umbral determinado, la motivación extrínseca resulta incluso contraproducente, dejando como única solución el trabajo en la motivación intrínseca.

Pero esas pruebas científicas y esas publicaciones de Daniel Pink no hacen nada más que corroborar la teoría de la autodeterminación (SDT), que es esencial en los mecanismos de motivación intrínseca y nos da las claves para que las personas que realizan este tipo de trabajo conceptual estén activas, estén también motivadas y sean creativas. Y en un entorno cambiante como el actual, en el que se mueven las empresas, no es necesario demostrar que este tipo de trabajo es el más crítico, y por ello consideramos las conclusiones de la SDT como uno de los fundamentos del trabajo en Agile. De hecho, veremos que Agile, tal y como está expuesto en Agilemanifesto.org, es una demostración empírica de la veracidad de la SDT.

Decíamos que la motivación intrínseca es la que nos impulsa a hacer cosas por el simple gusto de hacerlas, es decir, que la propia ejecución de la tarea es la recompensa. Los comportamientos basados en esta motivación son entonces aquellos que se realizan porque la principal recompensa son los sentimientos espontáneos de bienestar y disfrute que acompañan a dichos comportamientos. Pensemos en ver una película. La motivación intrínseca para esa labor nos puede parecer obvia, pero no relacionada con el trabajo. Ahora bien, si decimos que hablamos de alguien que se gana la vida como crítico de cine, esa labor sí que está relacionada con su trabajo. Es claro que dicho individuo estará encantado de ver las buenas películas, pero no tanto en tener que analizar y preparar críticas sobre los bodrios que llenan las librerías de las nuevas plataformas de entretenimiento. Pero tomando esto como referencia, ¿y si consiguiéramos que todos los empleados de nuestra empresa estuvieran tan motivados en hacer su trabajo como lo pudiera estar un crítico de cine en ver películas, sean buenas o malas?

Sabemos que Agile, con su mecanismo incremental y empírico, es útil sobre todo cuando se aplica a trabajo conceptual y creativo, aquel que es difícil de medir y cuyo valor a aportar en el futuro es difícil de predecir y estimar. El modelo incremental favorece el análisis de lo cercano y nos permite reducir el esfuerzo en predecir lo muy lejano. Por suerte, como veremos, los principios y valores de Agile también favorecen los requisitos que SDT muestra como necesarios para la motivación intrínseca, con lo que podemos cerrar el círculo: el trabajo conceptual y creativo es el necesario para un entorno cambiante, en el cual Agile es muy útil y, a su vez, favorece los requisitos para la motivación intrínseca, la cual es fundamental para el trabajo conceptual y creativo.

Como motivación intrínseca, SDT identifica tres necesidades psicológicas que sirven de nutrientes esenciales para el crecimiento, la integridad y el bienestar:

• Maestría (competence), o necesidad básica de sentirse capaz y efectivo sobre una materia que importe.

• Vinculación (relatedness), o necesidad de pertenecer a un grupo y sentirse importante y/o querido.

• Autonomía (autonomy), o necesidad de autorregular las propias experiencias y acciones. Sentido de voluntariedad, que no de independencia. 

Siempre se ha dicho que aplicar los valores y principios del Agilemanifesto.org implica trabajar en equipos autogestionados y multidisciplinares. SDT nos dice que es fundamental tener satisfechas estas tres necesidades: vinculación, autonomía y maestría. Por tanto, una célula Agile es un equipo (perfecto para fomentar la vinculación entre sus miembros), autogestionado (donde sus miembros se sienten autónomos en decidir cómo hacer su trabajo) y multidisciplinar (donde sus miembros se reparten las maestrías necesarias para acometer el propósito del equipo). Esto implica que, si un equipo es verdaderamente Agile, también tendrá cubiertas las necesidades esenciales para la motivación de sus miembros. Es decir, satisfará las necesidades esenciales para la motivación intrínseca.

Pero de nada sirve tener equipos muy motivados que trabajen en algo sin interés para la empresa. Si queremos motivar a los individuos que conforman la organización colaborando entre sí, pero también con la propiedad, habrá que añadir un propósito o una necesidad de entender que persiguen una meta, que van hacia algún lugar, y esta meta deberá estar perfectamente alineada con los intereses de la empresa. De esta forma, la maestría, o necesidad básica de sentirse capaz y efectivo en una materia relevante sólo tendrá sentido en el contexto de persecución de un propósito en el que dicha maestría sea esencial. Del mismo modo, la pertenencia a un equipo precisa de una misión que defina su alcance. Y finalmente, la autonomía también requiere de un propósito de aplicación, ya que de nada sirve tener autonomía y libertad sin una razón de ser.

Daniel Pink redefine estas necesidades con la tripleta maestría, autonomía y propósito, interpretando este último como la intención de hacer lo que hacemos.

Conclusión parcial para nuestro estudio: En nuestro modelo del ACF pensamos que se requieren las cuatro facultades: maestría, vinculación, autonomía y propósito. Desarrollaremos pues nuestro modelo sobre equipos autogestionados, multidisciplinares y con un propósito compartido.

4.2 Fuentes de Desmotivación

Tras la lectura de la sección anterior podríamos pensar que las medidas de motivación extrínseca, como el salario o la comodidad de una oficina, pasan a un segundo plano. Como veremos a continuación, esto no es así, y para argumentarlo usaremos los estudios de otro autor, Frederick Herzberg, creador de la Teoría de la Motivación-Higiene, que distingue entre:

• Factores motivadores: trabajo interesante, reconocimiento, responsabilidad, etc.

• Factores higiénicos: salario, seguridad, categoría, etc.

Según Herzberg y muy en línea con la SDT, aunque el segundo grupo de factores no motivan, pueden hacer al trabajador infeliz e improductivo, es decir, una promesa de incremento del salario no mejorará el rendimiento del trabajador en su trabajo conceptual y creativo del día a día, pero no cobrar un salario digno será un factor desmotivador, como también lo será el estar en un entorno poco confortable o sentirse ofendido por la categoría que le ha sido asignada.

Estos no son los únicos factores desmotivadores. A ellos hay que sumarles los asociados con la motivación intrínseca, que pueden tener varias causas:

• Que el sujeto no se sienta capaz de obtener un resultado, es decir, por falta de maestría.

• Que el sujeto no le dé valor o interés a manifestar un comportamiento concreto.

• Que el sujeto desafíe o se resista a la influencia exterior. Se trata, en realidad, de un comportamiento reactivo para enfrentarse a las imposiciones que estén frustrando una necesidad básica de autonomía o vinculación.

Conclusión parcial para nuestro estudio. En las distintas fuentes consultadas, se ha constatado que los factores desencadenantes de las percepciones de estar regulado externamente y de ser incompetente (tales como los plazos impuestos, la vigilancia y el feedback negativo) socavan la motivación intrínseca, mientras que aquellos factores que apoyan las percepciones de autonomía y el sentimiento de competencia (tales como las oportunidades de elección, el feedback positivo y/o el reconocimiento del ámbito de responsabilidad o acción de las personas) mantienen o mejoran la motivación intrínseca.

4.3 Niveles de Autonomía

Por una parte, veíamos en el capítulo anterior que los sistemas complejos están formados por múltiples partes autónomas, aunque no independientes, y también que la autonomía de los equipos es una necesidad esencial para la motivación. ¿Pero qué tipo de autonomía o, mejor dicho, qué grado de autonomía? ya que, como también hemos visto, es necesario compatibilizar esta autonomía con el alineamiento con los intereses de la empresa, y a mayor autonomía de los equipos menor capacidad de gestionar el alineamiento de sus propósitos.

Pero hay otra variable importante a considerar, relacionada con la propia capacidad del equipo para autogestionarse y hacerlo dentro del esquema de agilidad. Poniendo un ejemplo extremo, de nada serviría otorgar autonomía a un equipo si éste decide usarla para asignar el mando de forma rotatoria a cada uno de sus miembros. No es lo mismo un equipo autónomo de individuos experimentados en equipos ágiles, que un equipo de individuos junior sin ninguna experiencia en cualquier tipo de gestión. Por tanto, para determinar el grado de autonomía que se debe otorgar a cada uno de los equipos habrá que tener presente en primer lugar la madurez de cada uno de ellos.

Por otra parte, la autonomía está fuertemente ligada a las capacidades de autogobierno.

Así pues, podemos distinguir entre los siguientes tipos de equipos:

• Equipo auto-organizado, que organiza sus propias tareas y elige su organización interna.

• Equipo auto-designado, que elige a sus miembros.

• Equipo auto-gobernado, que funciona sin gobierno alguno del exterior, en lo relativo a la determinación de su propósito.

Los tres tipos de equipos son válidos, pudiendo presentar un grado variable de Agilidad y de Alineamiento con la Propiedad. En cualquier caso, como iremos viendo al profundizar en el ACF, no existe una solución óptima que sea la estándar para todos los casos. Usaremos el término auto-gestionado como un concepto ambiguo, que se referirá a aquella de las tres opciones que mejor se adapte a cada caso.

Conclusión parcial para nuestro estudio. Las startups suelen ser un ejemplo de autogobierno, pues en ellas el riesgo de desalineamiento no existe, ya que la Propiedad forma parte del equipo, mientras que su agilidad es máxima por cuestiones de envergadura. Lamentablemente, como veremos más adelante, la solución de los problemas de los sistemas complejos no se puede implementar mediante un sencillo escalado de las capacidades de autogobierno de una startup.

4.4 Conclusiones Generales de SDT

Según lo estudiado en este capítulo, podríamos llegar a una simplificación, quizás algo excesiva, de las claves del éxito de la Agile Corporation: todo funcionará si construimos una organización compleja adaptativa, formada por equipos autogestionados, con un propósito alineado con el propósito de la organización, con las maestrías que la hagan capaz de cumplir con dicho propósito de forma eficaz, y donde se hayan resuelto los factores higiénicos que causan desmotivación.

Por tanto, decimos que las células de la Agile Corporation tienen estas cuatro características:

• Son un equipo, satisfaciendo para sus individuos la necesidad de pertenecer a un grupo y sentirse apreciado en él.

• En la medida de lo posible son autogestionadas. Sus miembros participan en la autorregulación del grupo según sus propias experiencias y acciones.

• Son multidisciplinares, donde cada uno se siente capaz y efectivo sobre una materia que importe.

• Tienen un propósito propio, aceptado por todos sus miembros, que adoptan la intención de hacer lo que hacen.

5 Filosofía Agile

“The myth of innovation is that brilliant ideas leap fully formed from the minds of geniuses. In reality, most innovations are borne from rigor and discipline”

(“El mito de la innovación es que las ideas brillantes salen completamente formadas de las mentes de los genios. En realidad, la mayoría de las innovaciones nacen del rigor y la disciplina”)

“Change by Design”, Tim Brown

5.1 Introducción a Agile

Business Agility, o la Filosofía de la Agilidad aplicada al negocio, tiene sus raíces en el Desarrollo SW, lo cual no es por casualidad, ya que el mayor punto fuerte del SW es a la vez su mayor debilidad: la flexibilidad total. El SW es tan flexible que se adapta perfectamente al carácter de los desarrolladores que lo producen, lo cual es bueno si los desarrolladores son ordenados, disciplinados y autoexigentes. Pero puede llegar a ser malo si los desarrolladores son caóticos, dejados o inconstantes, aunque en ambos casos sean geniales programando.

Cuando se fabrica una pieza mecánica en la industria, el proceso extremo a extremo tiene pocos grados de libertad. Pensemos en una pieza de acero, que se ha de fabricar a partir de un bloque macizo de este material. Los ingenieros que la diseñan piensan en todas sus funciones y requerimientos, en la resistencia física y térmica del material, en su montaje y desmontaje, en su lubricación y mantenimiento, etc. Cuando tienen finalmente determinados todos los detalles con suficiente precisión, generalmente proceden a efectuar una simulación precisa del comportamiento de la pieza, previa a la fabricación. Hecho todo esto, el diseño resultante se envía a la fábrica y allí se mecaniza a su imagen el bloque de acero con matrices, fresas, tornos, limadoras, pulidoras, etc., y se templa mediante recocido en aceites sintéticos a la temperatura adecuada.

Si alguno de estos pasos de fabricación falla o hay algún vicio oculto en el diseño, casi nunca se puede ir marcha atrás. La pieza defectuosa será descartada y enviada a la fundición para su reciclaje, empezando otra vez desde el principio tras corregir el error detectado en la mecanización o en el diseño, lo cual es muy costoso. Algo similar ocurre en la fabricación de microchips, en la que el diseño y la simulación previos a la fabricación de las máscaras de insolaje duran meses, hasta que se asegura que la pastilla funcionará a la primera. No se admiten fallos. No se admite parchear el chip soldando un componente externo entre dos patas de un Quad Flat Pack de 100 pines con montaje en superficie sobre la placa base.

En este entorno del hardware la agilidad parece complicada de implantar desde este punto de vista, sin embargo y como iremos viendo, si bien las cadenas de montaje deben funcionar con la precisión de un reloj y con las eficiencias suficientes para ganar ventaja competitiva frente al mercado (Lean Manufacturing), el diseño de esos productos y de esas cadenas de montaje sí es un trabajo conceptual y creativo que en sí es flexible, difícil de predecir y difícil de medir.

Pero esta distinción entre el proceso de la cadena de montaje y el diseño del producto, y la propia cadena de montaje, no fue abordada de la mejor manera en el moderno mundo del software, resultando más que evidente cuando los equipos tuvieron que empezar a enfrentarse a los desarrollos relacionados con soluciones en la web. El enfoque inicial, el llamado modelo en cascada o waterfall, trataba el proceso de creación de SW como una cadena de montaje, a la que se denominaba metodología, donde el producto era el propio SW, como si éste fuese tan rígido, inflexible y medible como las piezas de hardware usadas en el ejemplo. Aún peor, esa metodología de desarrollo se trató como algo que podía ser estándar, igual para todo tipo de SW y todo tipo de equipos, y el mundo del SW es totalmente distinto. Por muy estricta que sea la metodología que gobierne el ciclo de vida, la cadena de montaje de SW, los equipos de desarrollo siempre codifican antes de terminar el análisis, entregan productos no suficientemente probados, resuelven los problemas de forma reactiva al aflorar los errores, etc. Históricamente, el sueño dorado de todo empresario TIC clásico siempre ha sido que sus equipos produzcan SW como si estuvieran fabricando HW, para asegurar que funcione a la primera y sin ningún parche posterior, no obstante, esto no va con el signo de los nuevos tiempos.

Las metodologías ágiles nacieron en su momento para tender un puente entre ambas formas de hacer las cosas, puesto que el dinamismo del mercado exigía al SW una respuesta casi inmediata en producción, sin acabar nunca de cerrar los requisitos en su totalidad. Estos tiempos tan cortos no permitían recorrer todos los pasos del ciclo de vida del SW, por lo que al final se entregaba la consabida versión beta con un rosario de Parches, pero la agilidad vino a asumir que esta forma de hacer las cosas no tenía por qué ser incorrecta ni mala del todo. La clave era normalizarla y controlarla, implementando un primer núcleo de SW operativo y controlando los parches posteriores que se entregarían de forma sucesiva, a los que se decidió denominar incrementos.

Todo esto ocurría en las dos décadas finales del siglo XX, en las que empezaba a resultar evidente que estaba cambiando el paradigma del desarrollo SW y se necesitaba una forma de desarrollar que permitiera gestionar los requisitos de forma abierta y cercana al usuario, evitándole los grandes y complicados diseños, imaginando las soluciones en detalle, aunque tardaran años en ser desarrolladas, como si se tratasen de jugadores de ajedrez que tuviesen que imaginar una larga secuencia de jugadas maestras, todo para cerrar los requisitos antes de que comenzara la segunda fase de la cadena de montaje, el análisis en detalle de estos detallados y prolijos requisitos, para poder luego diseñar el SW con precisión.

En su lugar, estas metodologías pedían identificar una primera entrega, idealmente aquello que más valor aportaba y menos esfuerzo requería, que se desarrollaba y se entregaba al usuario o propietario del producto, que podía entonces ver y tocar el resultado con objeto de imaginar el siguiente incremento ideal a desarrollar.

Todo ello bajo una estrategia global de producto, con una visión concreta, pero trabajando en equipo tanto el propietario/usuario como los desarrolladores y entendiendo que cada entrega podría ser verificada y aportaría más información, resultando más evidente el siguiente paso. Y, por tanto, esto sólo sería viable si todos adoptaban una actitud receptiva al cambio que implicaba la nueva luz aportada por cada entrega.

Las metodologías en cuestión eran las siguientes:

• Extreme Programming

• Scrum

• Dynamics Systems Development Method (DSDM)

• Adaptive Software Development

• Crystal

• Feature-Driven Development

• Pragmatic Programming

Si bien dichas metodologías rompedoras se concibieron por separado, los padres fundadores de las mismas sabían los unos de los otros, estudiaban con gran interés y respeto los modelos ajenos, y observaban con atención los progresos y retrocesos de sus colegas, hasta que finalmente decidieron reunirse en un foro informal para intercambiar sus experiencias, sacar factor común de las mismas y encuadrarlas en una nueva filosofía. Y de esta forma, en febrero de 2001, en la estación de esquí de Snowbird (Utah), diecisiete representantes de estas metodologías se reunieron para condensar las características comunes que presentaban las mismas, pues todas ellas daban claras muestras de abordar mejor el desarrollo de productos SW de lo que lo hacían las metodologías tradicionales o waterfall.

Entre todos ellos acordaron elegir el término Agile para denominar a la filosofía común de estas metodologías y así escribieron y firmaron el Manifiesto de Desarrollo de Software Agile (www.agilemanifesto.org), que se sustancia en los cuatro valores siguientes, que aunque fueron descritos al principio del libro, ahora mencionamos de la misma forma que aparecen en el manifiesto, relativos al desarrollo de SW:

• Individuos e interacciones sobre procesos y herramientas

• Software funcionando sobre documentación extensiva

• Colaboración con el cliente sobre negociación contractual

• Respuesta ante el cambio sobre seguir un plan

(aunque los autores valoran los elementos de la derecha, valoran más los de la izquierda)

Fuente: Agilemanifesto.org

Además de los valores, expusieron los doce principios derivados de los mismos y que ahora también representamos sin ninguna alteración respecto a su publicación en el manifiesto:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al período de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Así pues, a la pregunta común de qué es trabajar en Agile, para que una empresa, un equipo o un proyecto sean considerados Agile en este contexto, tendrían que cumplir tanto los cuatro valores como los doce principios anteriores, ya que el término fue reservado como hemos dicho para los equipos que asuman esos valores y cumplan esos principios.

Desde el equipo de Agile Corporation consideramos al Manifiesto Agile y a las metodologías en las que se inspira como una demostración empírica de la Teoría de la Autodeterminación (SDT) revisada anteriormente. Para afirmar esto, ya comentábamos que la aplicación de los principios implica irremediablemente la configuración de equipos autónomos y multidisciplinares, y nos basamos en el hecho constatado de que las personas que trabajan en equipos Agile correctamente montados muestran altos grados de motivación y, en ocasiones, incluso afirman ser felices con la situación. Por tanto, SDT funciona y los modelos de gestión basados en ella resuelven mejor los problemas a los que se enfrenta la empresa en este mundo cambiante. Por esta razón, nos hemos inspirado en la filosofía Agile para denominar a nuestro marco de trabajo Agile Corporation Framework (ACF).

En este capítulo no pretendemos exponer la filosofía Agile de forma pormenorizada (para ello, el lector deberá consultar bibliografía especializada), sino centrarnos en las claves de la denominada Agilidad de Negocio (Business Agility) para construir nuestro marco de trabajo ACF.

5.2 Qué consideramos Agile fuera del Desarrollo de SW

Aunque lo que realmente hizo emerger a las metodologías Agile fue el cambio de paradigma del desarrollo SW en los últimos tiempos, pronto se pudo comprobar que los valores y los principios del manifiesto también eran válidos para desarrollar cualquier otro tipo de producto.

Toyota Kanban Board

Fuente: kanbanize.com, Toyota Global Web

Esto tenía mucho sentido, puesto que algunas de las metodologías fundacionales del paraguas Agile ya tenían otras precursoras procedentes del campo de la gestión de procesos industriales, el Lean Manufacturing. Como ejemplo concreto tenemos a la metodología Kanban, nacida a finales de la década de los 40 del siglo XX para optimizar la producción automovilística en las factorías del Toyota Production System/Just In Time.

Si bien kanban no estuvo representada en la reunión de Utah, ahora está muy presente en las implementaciones de las metodologías Agile de desarrollo de SW. En este caso, la aportación ha sido inversa. Este modelo productivo eficaz en la industria ha tenido gran impacto en los modelos de desarrollo de SW. Siendo varias sus aportaciones, vamos a reseñar dos: por una parte, el esquema altamente visual de su tablero, fundamental para facilitar la coordinación del trabajo de los equipos y favorecer la transparencia del proceso, algo importante de cara a la autogestión; por otra parte, su fijación en limitar el trabajo en progreso (work in progress), aplicando el saber popular de que quien mucho abarca poco aprieta (stop starting, start finishing). Las columnas del tablero kanban muestran trabajos en un determinado estado, trabajos que se representan por tarjetas. Un aumento del número de tarjetas que quedan en una columna, o la cantidad de trabajo pendiente en ese estado, viene a señalar que, o bien el equipo está descompensado, con déficit de dedicación a trabajos en ese estado, o bien demasiados trabajos están a la espera de eventos externos, o que, en cualquier caso, hay algún factor que está dañando la eficacia y eficiencia del progreso. Ahora es raro ver un equipo de desarrollo de SW que aplique metodologías Agile y no use un tablero kanban para coordinar sus tareas.

Pero saliendo del mundo SW, la filosofía Agile resulta perfecta para cualquier trabajo de tipo conceptual y creativo por la semejanza con el puro método científico:

• Observación. ¿Qué llama la atención? ¿qué se necesita?

• Análisis, Cuestionamiento y Definición del problema. Un problema bien definido está ya medio resuelto.

• Planificación y Organización. Descomposición del problema en partes más pequeñas.

• Investigación, Exploración y Recopilación de Evidencias.

• Elaboración de una Hipótesis, basada en predicciones lineales, para testear en el siguiente paso.

• Experimentación para constatar la Hipótesis, definiendo variables e indicadores.

• Conclusiones, a partir de los resultados de la experimentación.

En este método empírico de desarrollo de productos, la filosofía Agile aplica muy bien. Cada incremento, cada nueva entrega, supone un aporte nuevo de información, una nueva experimentación sobre la cual sacar conclusiones y definir el nuevo paso. En línea con esto, en Agile Corporation hemos preferido redefinir el segundo de los valores del Manifiesto Agile que comentábamos en la sección anterior, pues resultaba ser demasiado específico para el Desarrollo SW en su origen, sustituyendo así las referencias al SW por referencias a cualquier tipo de producto. Y así, reiterando los valores mostrados ya en el capítulo inicial del libro, quedarían pues de la forma siguiente para aplicarse a cualquier tipo de proceso productivo:

• Personas y relaciones sobre procesos y herramientas

• Entregas de valor al cliente sobre protocolos internos

• Colaboración con el cliente sobre seguimiento de contrato

• Adaptación al cambio sobre seguimiento de un plan

Y como siempre, para evitar malentendidos, diremos que en cualquier caso se conserva el espíritu de base del Manifiesto, esto es, aunque los conceptos de la parte derecha siguen teniendo su valor, se valoran y priorizan más los conceptos de la parte izquierda.

Sin embargo, la filosofía Agile puede resultar aparentemente engañosa en primera instancia. Cualquier persona que estudie sus valores y principios estará rápidamente de acuerdo con ellos, por estar impregnados de sentido común. No sólo eso, sino que también se sentirá capaz de llevarlos a la práctica inmediatamente. Sin embargo, aunque Agile sea fácil de entender y aprender, puede llegar a ser complicado de dominar en la práctica, puesto que supone una ruptura con todo lo establecido y una alteración de la visión clásica de las cosas en el ámbito empresarial.

Del mismo modo y tras una revisión preliminar, es fácil caer en la trivialización del manifiesto Agile y pronosticar que se trata de una solución válida sólo para empresas tipo startup y pequeños equipos, pero demasiado arriesgada y anárquica como para aplicar a grandes empresas y proyectos complejos, por la misma razón anterior, esto es, por su carácter rupturista con todo lo establecido. No obstante, como hemos visto en el Capítulo 3 acerca de la Teoría de la Complejidad y como intentaremos demostrar en los capítulos dedicados a nuestro modelo ACF, si se dispone de las herramientas adecuadas y de un adecuado protocolo de transformación, Agile puede llegar a ser más poderoso en grandes organizaciones de lo que lo es en empresas pequeñas. Por tanto, el problema no radica en el tamaño, sino en su incompatibilidad con las estructuras tradicionales. Implantar Agile en una gran organización con garantías de éxito implica romper las jerarquías con las que tan seguros nos encontramos habitualmente. Y si bien esta sensación es realmente una falsa seguridad, como irá quedando expuesto a lo largo de este libro, un cambio organizativo en una gran organización es una tarea complicada, por lo que en este sentido también sería falso afirmar que implantar Agile es algo sencillo.

Un error común en la transformación Agile es pensar que su despliegue se resuelve reemplazando la estructura jerárquica con el establecimiento de una organización matricial. En estas organizaciones, a la jerarquía ejecutiva y a la cadena de mando existente, normalmente verticales, se le suele superponer otra cadena de mando paralela de carácter funcional y operativo (¿ahora tengo dos jefes?). La solución no es respetar lo establecido y montar un supragobierno coyuntural para la transformación o permanente para la agilidad. La auténtica solución es implementar y desplegar un modelo completamente nuevo, como veremos más adelante.

Tener Agilidad es cumplir el manifiesto Agile, y supone sobrevivir mediante la adaptación al cambio. Para Agile Corporation, Agilidad es la liberación de los agentes de aquellas interdependencias con el exterior, e incluso con ellos mismos, que limiten su capacidad de adaptarse al entorno y de aportar valor alineado con el propósito de la empresa, que también permita a ésta adaptarse al cambio, corrigiendo sus debilidades frente a nuevos actores, generando fortalezas que mejoren su ventaja competitiva, aprovechando las mejores oportunidades y evitando las continuas amenazas. Pensemos en la Agilidad como en algo disruptivo a nivel organizativo, pero que no viene a reemplazar a todo lo anteriormente establecido, sino a sumar una nueva perspectiva que garantice la supervivencia de la empresa como sistema complejo adaptativo.

Conclusión parcial para nuestro estudio: En Agile Corporation consideramos que Agile es una solución con mucho potencial para empresas grandes y complejas, sin embargo, se trata de una filosofía complicada de dominar, aunque aparente sencilla, y que conlleva un complicado cambio organizativo. Veremos en cualquier caso que el marco ACF propone un despliegue gradual basado en lo que denominaremos AEZ (Zona del Ecosistema Agile), que hace viable su aplicación en cualquier escenario.

Con estas premisas, ha llegado el momento de redefinir el concepto de Agilidad, que se utilizará profusamente en los capítulos posteriores aplicándolo a cualquier tipo de equipo, se dedique o no al desarrollo de SW.

Diremos que una célula, como parte operativa de un sistema complejo adaptativo y con conocimiento adecuado del entorno particular en el que se desenvuelve, tiene Agilidad cuando cubre las siguientes necesidades básicas:

• Es un equipo, cuyos miembros se sienten parte integrante del mismo y apreciados por el resto de sus miembros.

• Tiene libertad para elegir el propósito adecuado, si bien éste debe estar alineado con el propósito de la organización.

• Dispone de Autonomía para gestionarse de la forma más adecuada a las circunstancias particulares de cada situación.

• Posee las maestrías adecuadas para llevar a cabo el propósito o, en su defecto, dispone de acceso a servicios que satisfacen dicha necesidad.

Escalando estas características a nivel organización, las células constituyen equipos, los equipos forman áreas, y así sucesivamente podemos ir escalando el modelo hasta el final, como veremos más adelante. Para comprobar si un área de la organización tiene Agilidad, analizaremos el grado de agilidad que tienen las células que la componen, como veremos con mayor detalle en el capítulo de Gobierno.

Si nos preguntamos, por qué ahora es más aplicable que nunca Agile en la empresa, una de las razones está en que originalmente el trabajo conceptual y creativo estaba asignado a unos pocos en la empresa, normalmente a individuos relacionados con Estrategia y Marketing, o bien a los directores y gerentes de las distintas áreas funcionales. La velocidad del cambio producido por las disrupciones tecnológicas, junto con la inestabilidad e incertidumbre que reina en el entorno donde la empresa opera, exigen que ésta dedique mucho más esfuerzo a su propia reinvención que a mejorar y a aumentar la eficiencia de las cadenas de producción. La empresa actual demanda que la práctica totalidad de los empleados aporten ideas y participen en la creación de valor al cliente. El trabajo conceptual y creativo se extiende y democratiza, y asimismo la necesidad de su gestión en un modo Agile, con equipos autónomos multidisciplinares.

5.3 La Agilidad y las Jerarquías

Sí, Agile propone estructuras en las que las responsabilidades recaen en el equipo, aunque no en sus miembros. Nada que ver con las estructuras jerárquicas, donde cada individuo es responsable de lo que hace el equipo al que manda. Esta situación sin jerarquías requiere que ciertos individuos tengan maestrías específicas, sustenten un liderazgo servil en ciertas áreas, y se encarguen de ciertas funciones o actividades. Para mostrar la organización de un equipo sin jerarquías y cumpliendo con las características de Self Determination Theory y su funcionamiento con respecto a quién porta la responsabilidad y a la gestión de la misma, tomaremos como ejemplo un buen equipo de Fútbol:

• Para empezar, está más que demostrado que un equipo de Fútbol debe sentir que es un auténtico equipo para poder triunfar. Su propósito final como equipo es bien claro, aunque su ambición variará dependiendo de su nivel.

• Además, los distintos miembros del equipo poseen distintas maestrías. Los hay defensivos, creativos, buenos centradores y buenos rematadores, y algunos tienen funciones específicas, como es el caso del guardameta.

• En este caso no se trata de un equipo autodesignado, sino sólo autoorganizado, por lo que el entrenador selecciona los jugadores y marca una pauta, pero después el equipo es autónomo para moverse y tomar decisiones de la forma más adecuada a cada situación.

• Nadie es responsable en particular de marcar goles, aunque ciertos jugadores tienen claramente mayor maestría que otros en cumplir con este objetivo, por lo que ocupan posiciones más adelantadas. Por otra parte, el portero no es el responsable de no encajar goles, sino que todos, como equipo, son responsables de defender la meta.

Este mismo modelo es el que se aplicaría en un equipo Agile, en el que habría especialistas que propondrían al equipo las mejores soluciones en su campo, pero también en el que todo el equipo asumiría la responsabilidad sobre las decisiones tomadas.

Está sobradamente demostrado que Agile es la mejor forma de desarrollar SW, sin embargo, también está más que demostrado que la gestión tradicional es el mayor obstáculo para aplicar Agile. Ello se debe al fenómeno del aprendizaje supersticioso, que induce a pensar y opinar negativamente acerca de la nueva filosofía a aquellos directivos que han triunfado por hacer las formas a la usanza clásica. Incluso en algunas startups que evolucionan, mientras la clave de su éxito cuando son pequeñas es la delegación en su plantilla recogiendo, analizando e implementando casi en vivo los requisitos al dictado del cliente, cuando estas empresas alcanzan el éxito y su tamaño crece hasta convertirse en grandes Factorías SW, los antiguos y brillantes ideólogos y técnicos escalan hasta puestos directivos. Entonces empiezan a creer que las cosas sólo se pueden hacer a su manera, desconfiando de los nuevos técnicos, e implementando fuertes controles para asegurarse de que las cosas se siguen haciendo según sus designios al más bajo nivel de detalle. Craso error, pues lo correcto es gestionar adecuadamente la empresa al nivel correspondiente, dando responsabilidad y suficiente independencia a las nuevas generaciones de tecnólogos.

Las estructuras jerárquicas restan autonomía a las partes, restan adaptabilidad, y por tanto restan Agilidad. De igual modo, las responsabilidades individuales restan también autonomía al equipo y por lo tanto agilidad. “Si soy el responsable, seré premiado o castigado, por lo tanto, yo decido”, es decir, la responsabilidad que recae sobre alguien supone restricciones para el comportamiento del mismo individuo que es responsable, así como para el equipo de trabajo que está a sus órdenes o que debe acatar la decisión ya tomada.

Ahora bien, una vez aclarado que las jerarquías no ayudan a la adaptabilidad para la supervivencia de la empresa, ¿nos sentimos confortables para gestionar nuestras empresas como si de equipos de Fútbol se tratase? ¿es viable una empresa de cierto tamaño sin jerarquías? ¿podemos romper las jerarquías establecidas como si de cadenas se tratasen? Obviamente las cosas no son tan fáciles. Para empezar, tendrá que haber una fase de convivencia entre estructuras jerárquicas ya Agile, y las interdependencias jerárquicas deberán ser reemplazadas por otros tipos de interdependencias que aseguren el alineamiento.

Conclusión parcial para nuestro estudio: El ACF debe ser un modelo que permita combinar estructuras o relaciones jerárquicas con estructuras puras de Agile, y en el que no residan las responsabilidades en los individuos, sino en los equipos.

5.4 Agilidad con inteligencia

Para nosotros, la solución no consiste en disponer de equipos Agile, sino en gestionar la agilidad del conjunto como un sistema complejo adaptativo. Más agilidad significa también más independencia entre los agentes que componen el sistema. Más agilidad significa asimismo más libertad en los agentes para operar a su libre albedrío. Pero en el mundo cambiante donde la adaptación al medio es crítica, la agilidad en grado máximo puede surgir como un deseo, pero sabemos por experiencia que su exceso puede conducir al caos. Para tener éxito será necesario mantener alineados los propósitos de las células y ejercer un cierto grado de control o gobierno para garantizar la viabilidad del sistema en su conjunto. No podemos confiar en la Selección Natural que gobierna los sistemas complejos en la naturaleza, que tiene lugar debido al cambio espontáneo y repetido que finalmente logra la adaptación al medio, en la que la mayoría de las alteraciones o mutaciones no prosperan y sólo unas pocas mejoran la adaptación del sistema al entorno. En nuestro caso el método de elección de “mutaciones” debe ser científico, por lo que necesitamos aplicar inteligencia a los cambios para intentar minimizar las decisiones que lleven al fracaso, proceso que constituye una selección dirigida, que reduce las situaciones incorrectas y ahorra tiempo en la evolución. A efectos prácticos, esto lo conseguiremos mediante la creación de relaciones de dependencia entre las células de trabajo y aquéllas otras que representen a la Propiedad.

Esta inteligencia en el cambio resulta esencial. Agile permite y fomenta el cambio continuo, no obstante, el libre albedrío no es todo bueno, puesto que estos cambios hay que gestionarlos, hay que modularlos. Veamos un par de casos ilustrativos.

La industria de la automoción de Detroit fue en su momento la más grande y poderosa del mundo. Ante el exagerado aumento de los salarios y el poder desmedido de los sindicatos, los directivos de las grandes fábricas automovilísticas, en un esfuerzo de adaptación al medio, quisieron abaratar los costes de producción optando por la subcontratación de la fabricación y suministro de ciertos componentes de los vehículos, así como la deslocalización de parte de su producción. El abuso de estas tácticas dio lugar a que los fabricantes asiáticos de piezas llegaran a tener en un momento dado toda la tecnología, utillaje y diseños suficientes como para ensamblar sus propios coches. Oriente inundó el mercado norteamericano con coches baratos que provocaron el colapso del sistema productivo de Detroit. En este caso, los cambios incorrectos o incorrectamente gestionados provocaron la caída de un sector industrial de alto rango.

Pero también existen contraejemplos. Kodak, el todopoderoso gigante de la fotografía durante un siglo cayó en picado debido a su mala estrategia. En el año 1975 sus brillantes técnicos desarrollaron la primera cámara digital de la historia, pero sus directivos, reprimiendo ese ejercicio de adaptación en un esfuerzo por evitar que un equipo autónomo de su empresa canibalizara el resto, arrinconaron durante un tiempo precioso esta invención por miedo a que afectara al negocio tradicional, en el que confiaban plenamente. Cuando la competencia lanzó sus cámaras digitales, Kodak quiso recuperar la suya y lanzó una tardía e ineficiente estrategia digital que no llegó a tiempo como para frenar lo que se avecinaba. Este retraso competitivo resultó crucial en la carrera comercial, que Kodak perdió aun disponiendo de medios y de datos suficientes como para poder evolucionar en el sentido adecuado. En este otro caso, la ausencia de cambios o su gestión incorrecta provocaron la caída de una empresa centenaria y de supremacía mundial.

Por tanto, aunque parezca una obviedad, no se trata de aplicar agilidad por el mero propósito de hacerlo, o fomentarla en su máximo exponente. Pero tampoco podemos optar por estrategias demasiado conservadoras que impidan la adaptación a tiempo. El ritmo lo marcará el mercado, el modo será específico de cada caso, y la inteligencia para hacerlo deberán aportarla todos los líderes serviles de los que disponga la empresa.

Y es que Agile puede llegar a ser fantástico, pero sólo si el equipo lo es. El manifiesto Agile no recoge la necesidad de tener un equipo competente, ni unos gestores inteligentes, sino que asume que los equipos tienen las maestrías y que además todos los integrantes del equipo son personas cabales. Como sabemos, la realidad puede ser bien distinta. Es cierto que un equipo puede autogestionarse y escalar o solucionar problemas que surjan con alguno de sus miembros, o bien, lidiar con maestrías necesarias que no posea, pero esto no significa que cualquier equipo vaya a ser capaz o competente para cumplir con su misión de la forma adecuada. Continuando con el ejemplo del equipo de Fútbol, once jugadores incapaces no van a constituir un buen equipo por el simple hecho de sentirse un equipo, de tener autonomía, o de ser especialistas en algunas de las posiciones esenciales en el campo y tener el firme propósito de ganar algún título.

De igual manera hay que poner inteligencia no sólo en la formación del equipo, sino en cómo se engrana éste en el conjunto de la organización. ¿Quién garantiza que un equipo, con su visión parcial del sistema, no pueda poner en jaque al conjunto? Imaginémonos al operador de bolsa que pone en riesgo toda la empresa en busca de una racha de suerte que le reporte un buen bonus ese año, o a un equipo de creativos de marketing con exceso de visión que lleven a la empresa a lanzar campañas arriesgadas.

Tampoco debemos olvidar el aprovechamiento inteligente de las sinergias corporativas, que constituyen la única ventaja de una corporación frente a una startup. Dar autonomía a los equipos no puede resultar en que éstos, por desconocimiento o por desprecio, dejen de utilizar dichas sinergias. Nos referimos no sólo a la gestión del músculo financiero, sino también a la disposición de maestrías y servicios especiales normalizados, allá donde la economía de escala sea importante o donde la doble especialización técnica y de negocio los haga demasiado caros para una startup. Todo lo que en una gran corporación constituyen servicios normalizados y sinérgicos, pulidos a lo largo de los años y con unos costes fijos importantes pero contenidos, supone un gran gasto para una empresa pequeña. En una startup suelen echarse de menos el Gabinete Jurídico, las aplicaciones de Contabilidad y Facturación, la cadena logística inversa para devoluciones de ítems, los almacenes y su gestión, etc.

Conclusión parcial para nuestro estudio: Es necesario un gobierno externo a la célula que pueda corregir posibles disfunciones del sistema, gestionar riesgos globales y fomentar sinergias corporativas. Pero la clave está en aplicar sólo aquellas relaciones de dependencia necesarias para asegurar el alineamiento, pero que supongan una menor merma de agilidad. Analizaremos este punto más en detalle en los capítulos de Escalado y de Gobierno, pero resulta obvio que esto representará un gran reto para los gestores.

5.5 El Sistema Moldea la Cultura

Estamos hablamos de muchos cambios y la cultura del lugar va a suponer un bloqueo a tanta disrupción. Pero quisiéramos profundizar más sobre cómo funciona la cultura, vista desde dentro de un sistema complejo adaptativo. Para ello, partamos de la declaración en Business Agility que proclama que las métricas moldean los comportamientos.

Esta sentencia es más profunda e importante de lo que parece. Está basada en el mecanismo de acción-reacción que gobierna cualquier sistema complejo. Si tengo un equipo con cierta capacidad de autogestión, en el momento que incorporo una métrica, una medida de su comportamiento, los individuos que lo integran comenzarán a interpretar el objetivo de dicha medida, adaptando sus comportamientos en un intento de salir beneficiado de la medida. Es pura estrategia de supervivencia, pero sus efectos pueden ser muy perjudiciales. El resultado de la adaptación, ese efecto de reacción, puede no ser tan predecible, y cuando implantamos una medida a primera vista inocente podría conllevar unos efectos no deseados.

Queremos elevar este juicio al nivel de la organización. Muchos piensan que la cultura hace al sistema, pero en realidad es el sistema el que moldea la cultura. Recordemos para ello conceptos del capítulo de teorías de la complejidad y una definición de cultura apuntada cuando hablábamos de gestión de patrones como mecanismo de gobierno: “para conocer la cultura de un lugar, pregunta al más viejo del lugar qué hay que hacer para sobrevivir allí”. Los integrantes de un sistema siempre intentan sobrevivir en él, moldeando sus comportamientos para adaptarse al entorno. A su vez, en su afán por sobrevivir, los que no estén bien adaptados al sistema intentarán cambiarlo, pero los que estén muy adaptados, normalmente en posición de ventaja, rechazarán los posibles cambios. Por tanto, si queremos cambiar la cultura, tendremos que imponer cambios en el sistema, pero deberemos hacerlo con una estrategia medida que no dañe al sistema en su conjunto.

En cualquier caso, por los motivos mencionados casi todos los sistemas presentan cierto rechazo al cambio y, por tanto, es verdad que la cultura se opone en parte al cambio en el sistema. No obstante, no es válido tratar la cultura actual de la empresa como algo a combatir, o simplemente como una barrera infranqueable, sino como algo a moldear buscando que favorezca dicha transformación, ya que la cultura actual es el resultado del sistema actual. La cultura de un país es fruto del sistema establecido. Lo mismo podemos decir de una empresa o de cualquier organización, e incluso de una familia. Es evidente que la cultura es algo que tiene inercia propia y no puede cambiarse de un día para otro.

Pero veremos que, aunque no de un día para otro, sí se puede cambiar. Requiere, como veremos más adelante cambios en el sistema, de forma que los individuos se vayan viendo obligados a cambiar sus comportamientos no deseados para adaptarse y sobrevivir en el nuevo entorno. También serán necesarias nuevas mecánicas para favorecer el cambio mediante estímulos que lleguen a los agentes del sistema y tiempo para que dichos agentes, los individuos y las células, vayan aplicando sus grados de libertad para irse adaptando al nuevo sistema establecido. La comunicación y el voluntarismo pueden ayudar, pero sólo alterando el sistema haremos cambiar la cultura. Es por tanto un juego de tira y afloja, de mano de hierro en guante de seda, incorporando cambios con la convicción y determinación que imposibilite la vuelta del sistema al estado de equilibrio inicial, pero evitando al mismo tiempo la rotura traumática del sistema.

Una forma de asegurar que esos cambios, que serán un compendio de reorganizaciones, rediseño de las métricas, rediseño de procesos, etc., no acaben mal es el uso del propósito como mecanismo de alineamiento. Hay que darle a cada equipo la autonomía para adaptarse al cambio, asumiendo un propósito propio alineado con el propósito de su área, y éste alineado con el de la empresa y los intereses de la propiedad. El propósito es crítico en un sistema complejo, pero a su vez, es en sí mismo complejo de gestionar. Será clave el alineamiento de todos los propósitos de las células para conseguir un cambio cultural que permita transitar a la empresa hacia un nuevo estado (llevar a cabo una transformación de sí misma) pero hacerlo de forma alineada con el propósito de la organización.

6 Sobre el Marco de Trabajo Agile Corporation

“El marco encuadra la pintura, pero ésta tiene vida por sí misma”

agilecorporation.org

6.1 Un modelo en evolución

A la hora de hablar sobre los sistemas complejos aprendimos que no hay un modelo estándar válido para todos los casos, lo cual es aplicable también a nuestro Agile Corporation Framework. Con lo cual, nuestro modelo sólo puede pretender funcionar como un marco de trabajo para que cada cuerpo directivo construya su propio modelo, ajustado a sus realidades y circunstancias

Además, nosotros aplicamos la filosofía Agile a nuestro propio modelo, viéndolo como un producto que irá evolucionando, afinándose en cuanto a sus recetas y extendiéndose en la profundidad de las mismas. Por tanto, de lo único que podemos estar seguros hasta el momento es de que el modelo no será perfecto y de que necesitaremos nuevas versiones con nuevas adaptaciones para pulirlo y completarlo.

En ACF estamos siempre en construcción

En resumen, ACF es un marco abierto y en construcción, que no aporta soluciones concretas a los problemas concretos de las organizaciones actuales. ACF pretende ofrecer las claves para que los gestores de dichas organizaciones puedan establecer las bases y modelos correspondientes en sus empresas, con objeto de alcanzar la máxima agilidad posible, permitiendo el aprovechamiento de las oportunidades que surjan en el entorno cambiante en el que se encuentran, identificando e implantando al mismo tiempo un propósito global alineado con los intereses de todos los stakeholders.

6.2 No olvidemos la Propiedad de la Empresa

Decía Steve Blank que una startup no es una pequeña versión de una empresa. La gran diferencia estriba en que mientras que una corporación ejecuta un modelo de negocio, una startup va de fracaso en fracaso, adaptándose al medio e iterando en busca de su modelo de negocio ideal. Por tanto, haciendo caso a Blank, uno de los padres de Lean Startup, no podemos pretender ser una corporación o empresa con un modelo de negocio determinado y una startup a la vez. La situación habitual es tener una empresa que ya genera un valor y que encontró en el pasado su modelo de negocio, pero cuyo estatus se ve amenazado por los cambios en el entorno. Es en ese sentido en el que la corporación quiere actuar como una startup, pues desea buscar su nuevo modelo de negocio aprovechando las complejas y continuas oportunidades que surgen de la digitalización, necesitando al mismo tiempo preservar el modelo anterior hasta que se agote. Esto no se puede hacer con la simplicidad natural de las verdaderas startups, esto es, sin contar con las sinergias internas establecidas, ni con los controles que eviten grandes riesgos de pérdida.

Veámoslo de otro modo. Si en una organización nadie poseyera activos, tampoco se necesitaría a nadie para gestionarlos, pero los propietarios de la empresa, sus accionistas, sí que poseen activos, aquellos relativos al valor de la empresa. Por tanto, es necesaria una gestión de la propiedad en ese sentido, aparte del propósito natural de aportar valor al cliente. Es decir, no todo es sólo aportar valor al cliente, aunque este sea el mecanismo que nos lleve al éxito final, sino que debemos preservar también los intereses del accionista.

Esta situación no es tan compleja en una startup, donde ocurren dos cosas en su favor:

1. El valor de los activos a gestionar, el valor de la empresa, suele ser pequeño aunque vaya creciendo conforme crezca el éxito de la startup. En cualquier caso, todos los activos en riesgo son los de la propia iniciativa.

2. La propiedad está muy cerca de las operaciones y de los resultados. En este caso, tanto los riesgos como el valor aportado al cliente resultan ser obvios y transparentes para todas las partes que intervienen en la startup, incluida dicha propiedad, no siendo necesarias complejas estructuras de gobierno y control, ni la implementación de pesadas métricas ni indicadores.

En una corporación que quiere buscar nuevos modelos de negocio, como una startup, la situación es distinta:

1. Por una parte, la Propiedad se encuentra con la necesidad de defender el modelo de negocio de la empresa actual que, a diferencia de lo que ocurre en la startup, supone el sustento de las operaciones y un gran valor a defender por parte del accionista.

2. Por otra parte, en el caso de grandes corporaciones la Propiedad se encuentra muy lejos de las operaciones, con lo que se ve en la necesidad de establecer los controles necesarios para asegurar la defensa de sus intereses y de establecer las jerarquías que los preserven.

Ante esta situación, ACF no es una metodología ni un proceso definido, sino un marco de trabajo abierto para facilitar la gestión por parte de la Propiedad, que trata a su empresa como el sistema complejo adaptativo que es, gestionando la libertad que le permite evolucionar y adaptarse, autoorganizándose como un sistema inteligente que adopta la máxima ventaja competitiva en la aportación de valor al cliente, pero buscando también garantías de alineamiento de las partes con el interés del accionista, a pesar de su complejidad.

¿Y cómo podemos garantizar el alineamiento y a la vez cumplir con las necesidades esenciales de SDT (Self Determination Theory)? Necesitamos buscar alineamiento, pero a la vez buscar siempre la máxima autodeterminación de las partes. A más gobierno, más interdependencias entre dichas partes, menos autodeterminación y, por tanto, menos agilidad.

Con base en lo dicho se explica mejor lo comentado en el Capítulo 2 al hablar del Yin-Yang de Gestión del Propósito, donde se proponen dos fuerzas contrapuestas como características básicas de cada modelo construido dentro de ACF:

• Agilidad del sistema, maximizando la motivación y la agilidad de cada célula mediante trabajo en equipo, autogestión, dominio de las maestrías requeridas y propósito, que será entendido como propio de cada célula.

• Alineamiento de los propósitos de las células con el propósito de la organización (su misión), de forma que emerjan mayor productividad y eficacia como propiedades del sistema.

Dicho alineamiento lo conseguiremos mediante un gobierno que intentaremos que sea también ágil, que dé soporte a los equipos en su mejora continua, que gestione los riesgos por umbrales y que fomente las sinergias globales. Si bien este yin-yang puede parecer imposible, a lo largo de este bloque veremos cómo sí es posible y especialmente en el siguiente, donde proponemos herramientas y mecanismos para conseguirlo.

Repetiremos muy a menudo que las soluciones simples no existen y que las soluciones estándar no funcionan para gestionar sistemas complejos. ACF facilita la tarea del equipo de gestión para conducir la transformación de la empresa, pero sigue exigiendo, como no podría ser de otra forma, el esfuerzo de análisis, diseño e implantación de estrategias de gestión.

Para simplificar el problema diferenciamos entre la estrategia de gestión del sistema y las estrategias de los productos y servicios que lo componen. Es decir, en ACF la responsabilidad de la gestión del sistema recaerá en unos equipos distintos de aquellos equipos responsables de la gestión de las estrategias de los productos, aunque existan, como debe ser, relaciones que alineen ambas estrategias. Esta separación es clave para maximizar la agilidad manteniendo el alineamiento.

Otro tema de interés en el modelo es la propuesta de que los gestores, ya sean del gobierno del sistema global o de los productos, “cambien/ajusten el chip” y ya no sigan el modelo de altos directivos responsables únicos de un área de negocio. En ACF los gestores trabajarán en equipo, y dicho así parece razonable y obvio, más aún si lo que hacen es trabajo conceptual y creativo.

Puede que estos gestores formen parte de un equipo de trabajo como unos miembros más, desempeñando sus respectivos papeles pero sin la capacidad de orden ni de mando. También pueden pertenecer a un equipo de gestión, pero sin gente a su cargo, aunque con la suficiente influencia como para hacer que los otros equipos del sistema, autogestionados, alineen su operativa hacia el propósito establecido.

A lo largo del desarrollo de este bloque podría parecer que proponemos una estructura sin gestión y eso sería un lamentable malentendido. Tal y como mencionábamos al principio de este capítulo, consideramos que hay un activo que gestionar, un valor de empresa que defender, unos intereses de la Propiedad que perseguir. Sólo con un equipo de gestión que facilite el alineamiento de las células de trabajo podremos conseguirlos, aunque como se verá, esto sea gracias a relaciones de influencia (interdependencias) en lugar de relaciones de mando (jerarquías).

Dado que hemos planteado el modelado de una empresa como un Sistema Complejo Adaptativo, utilizaremos la CT (Complexity Theory) para obtener la inspiración necesaria para encontrar la estrategia de gestión más adecuada en cada momento.

6.3 El Ecosistema Agile

Concebimos el concepto de Agile Corporation Framework (ACF) como un mapa To Be al que creemos firmemente que toda empresa debe dirigirse. Se trata de una organización compleja adaptativa que acoge bien a los equipos ágiles que aprovechan las oportunidades que ofrecen los cambios en el entorno, especialmente los relativos a la digitalización.

Al mismo tiempo permite su gobierno, el aprovechamiento de las sinergias de la corporación y la gestión de sus riesgos. Al ser un mapa To Be, requiere compatibilidad con cualquier mapa As Is de partida. Por ello, nos referiremos a él como ”el ecosistema”, ya que lo entendemos como algo contenido en la organización tradicional. Ya hemos hablado anteriormente de AEZ como un ecosistema primigenio integrado en la empresa, y sobre su composición, escalado, complejidad y gobierno. En los capítulos posteriores iremos revisando más en detalle cada uno de estos tópicos.

Pero antes vamos a ver como se interpretan en ACF los conceptos tratados en el Capítulo 3, en el que se ha revisado la Complexity Theory. De esta manera iremos perfilando cómo hemos aplicado estos conceptos para fabricar un modelo que, siendo un sistema complejo adaptativo, pueda ser gestionado de forma centralizada:

• Los llamados “agentes” en la teoría de la complejidad, serán las células del ACF y los individuos. Son los componentes básicos del sistema.

• Las “mecánicas” son un tipo de estímulos artificiales que provocamos para dirigir la evolución del sistema hacia un To Be deseado. Los agentes deberán afrontar estos estímulos con Agilidad, como mecanismo de aprendizaje.

• Los “esquemas” forman lo que llamamos en ACF interdependencias. Los primeros son plantillas que definen cómo interpretar la realidad y cómo responder a un estímulo. Las segundas representan las relaciones entre células que canalizan los estímulos. La respuesta correcta y Ágil de los agentes ante una mecánica como las comentadas en el párrafo anterior tendrá como resultado el cambio de esquemas que corresponda en cada coyuntura.

• En ACF usamos el concepto “etiquetas” de CT para inventar las maestrías, los productos, los servicios, etc., que definen cómo se comportan los agentes y por tanto cómo interactuar con ellos.

• Las etiquetas comentadas en el párrafo anterior facilitan la formación de agregados o meta-agentes. Los meta-agentes ayudan a distribuir funcionalidades, permitiendo así que la especialización y la diversidad prosperen. En ACF los meta-agentes son los equipos.

Dicho todo esto, necesitamos una organización basada en un sistema operativo que haga funcionar a los equipos ágiles que componen el ecosistema. Esto nos lleva a exponer el modelo empezando por estudiar su composición básica: sus células y la forma en que funcionan.

Pero es obvio que si estas células estuvieran dejadas a su libre albedrío provocarían el caos en la organización. Es importante pues entender cómo se relacionan y cómo el sistema escala y gana complejidad dentro de un orden.

Por otra parte, debido a que la propiedad queda irremediablemente lejos de la operación, la delegación de decisiones autónomas a bajo nivel en una organización compleja requerirá de un gobierno, que tendrá que ser también complejo para ser efectivo.

Y todo ello tendrá que estar ordenado dentro de una organización que funcione, donde los propósitos de cada una de las partes estén definidos y se alineen de forma orquestada para conseguir la misión definida por su dirección.

Por tanto, tenemos cuatro capas bien definidas para explicar el modelo: su composición, su complejidad, su gobierno y su organización. Usaremos este esquema para exponer una primera introducción en este capítulo a cada una de ellas, dándonos una idea de conjunto, y luego entrar en profundidad en cada capa para explicar y analizar cada uno de los mecanismos y herramientas disponibles para la aplicación del modelo.

6.4 De la AEZero a la AEZone

La forma más inteligente de desplegar el modelo ACF en una empresa jerárquica es mediante una estrategia progresiva, que resulte lo más inocua posible.

Para ello, el punto de partida inicial supondría desplegar un pequeño ecosistema inicial, que hemos llamado Agile Ecosystem Zero o AEZ, que sería la mínima expresión posible del ACF que resulte operativa al estar integrada en el contexto de la empresa.

A partir de dicho ecosistema inicial, el ACF iría creciendo paulatinamente para ir desplegándose en todas las áreas de la empresa, mediante la progresiva incorporación de células Agile. La implantación es un proceso continuo y por tanto tendrá que convivir como parte de la empresa jerárquica, lo cual no supone ningún problema debido a la capacidad de adaptación intrínseca de un sistema complejo adaptativo, aunque ello no evita que la agilidad de la AEZ se pueda ver afectada siquiera transitoriamente.

Esta estrategia de despliegue gradual es connatural con la filosofía Agile de la Integración Continua, a través de la cual se van materializando y poniendo en producción los diferentes incrementos resultantes de los Sprints.

Así pues, a medida que se vayan incorporando más células a la AEZ, generando las correspondientes interdependencias con otras células Agile y con el resto de la organización jerárquica, el área de influencia de ACF también crecerá, convirtiéndose en algo natural en la organización, y pasando de ser el Agile Ecosystem Zero a ser la Agile Ecosystem Zone, pero manteniendo el mismo acrónimo.

Si el despliegue se hiciera bien, el resto de la empresa jerárquica notaría mínimamente los efectos secundarios de dicha implantación progresiva.

Una vez recorrido el modelo a nivel general, donde se puede ver cómo encajan las piezas que lo forman, vayamos a su análisis más detallado, dedicando un capítulo para profundizar en cada una de las capas del modelo.

7 Sobre su Composición

7.1 Cómo es una Agile Corporation

Como hemos visto en el capítulo anterior, una Agile Corporation es fundamentalmente una empresa cuya filosofía está basada en metodologías ágiles. No obstante, a diferencia de otras empresas que aplican estas metodologías, una Agile Corporation considera que las metodologías Ágiles son un juego de herramientas imprescindible, pero que para conseguir desplegar con éxito estas metodologías y jugar en ligas mayores, hace falta algo más.

Este nuevo componente a añadir, no tiene carácter infraestructural sino supraestructural, esto es, es algo que respeta la organización de una empresa en células Agile ortodoxas y le superpone una cultura de Corporación Ágil que se materializa a través del Agile Corporation Framework, como hemos visto anteriormente.

Una vez mencionado su carácter de supraestructura, vamos a profundizar en su composición y en su filosofía.

Para ello debemos identificar el nivel de escalado en el que nos vamos a fijar, determinando quiénes son los agentes que componen el sistema. En realidad, los agentes básicos que son capaces de cambiar y organizarse son los individuos. Sin embargo, ACF se basa en células como partes indivisibles, ya que creemos que este criterio es aplicable a todas las funciones de la organización, incluidas las de gobierno, y que además tiene la ventaja de obtener el beneficio completo de la SDT, resolviendo de entrada todas las consideraciones de motivación, tanto intrínseca como extrínseca.

Sin embargo, aunque en este mundo complejo no hay soluciones ideales y podríamos tener células unipersonales, de un solo individuo, el hecho de considerar a la célula como parte mínima e indivisible conlleva la idea de que dentro de una célula los diferentes individuos llegan a un grado de comunión y polarización tan alto, que finalmente se comportan como un todo. Aunque es cierto que puede haber un proceso transitorio de adaptación entre individuos para que una célula llegue a comportarse de esta forma, si ésta se constituye correctamente y con las maestrías adecuadas, este transitorio debería ser muy corto o casi inapreciable para un observador inercial que esté fuera de la célula.

Una recomendación importante es que un individuo no esté en dos células al mismo tiempo ya que, de hacerlo, tendría que compartir su compromiso con dos equipos distintos, o bien, participar en trabajos dependientes entre sí que podrían bloquearse mutuamente. Así pues, cada individuo deberá estar en un solo equipo, aunque pueda ayudar o asistir eventualmente a otro, o establecer una colaboración estable mediante una interdependencia reglada entre ambos equipos.

Para completar el escenario, es importante también tener presente el concepto de Product Ownership, que constituye la propiedad de los equipos sobre el producto que desarrollan, la labor que realizan, o el propósito que persiguen. Todas las células deberán funcionar con la mentalidad de estar construyendo un producto, aunque dicho producto sea el modelo de gobierno del propio sistema.

Como ya hemos comentado, toda célula tiene un componente de ideación y otro de desarrollo en mayor o menor medida. Sea cual sea el propósito y sea cual sea el papel de la célula dentro de un conjunto de células, siempre existirá un trabajo de ideación, entendido como la determinación de lo que hay que hacer para alcanzar el propósito, y siempre existirá un trabajo de desarrollo, entendido como la determinación del cómo y la propia ejecución de dicho desarrollo. Dentro de una misma célula, el equipo no estará claramente segregado entre una y otra función, aunque dependiendo de las maestrías de cada miembro, éste se dedicará en menor o mayor medida a una de ellas y a la otra.

A medida que crezca la demanda de trabajo, la célula podrá dividirse en dos partes, dos células: una especializada en la ideación y otra en el desarrollo. Estamos hablando de la misma gente en su mayoría, excepto los nuevos miembros añadidos, y hablamos del mismo propósito tanto antes, cuando se trata de una célula, como después, una vez dividida. Por tanto, cabría pensar que su funcionamiento no podrá ser muy diferente antes y después de su división, y así es, excepto unas pequeñas pero relevantes diferencias.

La célula inicial podrá y deberá tener sus artefactos y ceremonias que ayuden a todos los miembros a coordinar sus trabajos, a orquestarlos. Cuando la célula se parte, cada célula resultante necesitará sus propios artefactos y ceremonias independientes, pero al menos un artefacto y una ceremonia deberán surgir entre ambas para coordinar sus propósitos de forma adecuada. La célula de ideación, aquella de la división que se encarga de mayor carga del “que”, se relaciona con la otra de desarrollo, más enfocada al “cómo”, a través de al menos un artefacto que determine el “qué“ (generalmente un backlog de producto, y posiblemente otro adicional de incrementos), y para hacerlo efectivo lo más adecuado es establecer una ceremonia en las que ambas participen (como podrían ser las de planning para gestionar el backlog de producto, o las reviews para analizar el incremento resultante del trabajo de la célula de desarrollo.)

Por otra parte, hay que decir que los miembros de las células no deberían tener una asignación permanente, pudiendo pasar del uno al otro lado del backlog según las necesidades que vayan surgiendo.

Podríamos simplificar diciendo que las células son en realidad un conjunto de individuos muy próximos e interconectados, que funcionan como un sistema complejo en sí mismos. Estas células llegan a adquirir identidad propia en el sistema, por lo que en algunas ocasiones podemos llegar a verlas como entidades indivisibles.

Estas células se desenvuelven en la cultura de la empresa como una mezcla de lo que llamaremos el “Sistema Operativo” (S.O.), refiriéndonos a un entorno de trabajo donde reinan las necesidades esenciales de la self-determination y los “Valores” que, como veremos, emergen como lo hacen los patrones en los sistemas complejos.

Ya mencionamos anteriormente que esas células se relacionan u organizan en equipos, como grupos de individuos que trabajan juntos, comprometidos en realizar las entregas de valor.

En el modelo ACF consideramos que toda actividad puede clasificarse como uno de estos dos tipos de función, que podemos llamar trabajo de ideación y trabajo de desarrollo. Estos tipos de trabajo existen a nivel de cualquier célula y existen en mayor o menor medida siempre los dos tipos, independientemente de si hablamos de una célula de “desarrolladores de SW” o de “gestores estratégicos”.

Esto es así porque en realidad esta diferenciación es relativa pues, según el punto de vista, el trabajo de desarrollo puede ser considerado de ideación por parte de la célula encargada de realizarlo. Por ejemplo, una célula idea un producto y delega en otra su desarrollo, pero para ello ha tenido que “desarrollar” la idea y “desarrollar” el artefacto adecuado para que la célula de desarrollo pueda tomar el testigo. Pero cuando esta segunda célula arranca con el desarrollo, necesita “idear” cómo desarrollarlo entre las infinitas alternativas posibles, delegando posiblemente partes de dicho desarrollo en una tercera célula. En este caso, la célula de desarrollo idea en parte el trabajo de la tercera célula.

Aun así, entendiendo que es una clasificación relativa, cuando analizamos la relación entre dos células en la que una desarrolla una idea para conseguir un propósito y la otra debe hacerlo realidad, llamaremos célula de ideación a la primera, que tiene más carga de ideación desde el punto de vista de ese propósito, y célula de desarrollo a la que recoge el testigo.

La naturaleza de este propósito de las células determina su clasificación en el modelo:

• Aquellas encargadas de crear, desarrollar y/o operar un producto o parte de él, diremos que pertenecen al “área de Productos”.

• A las que tengan la misión de dar soporte al resto de células las situaremos en las “áreas de Expertise”.

• Por último, las células del “Agile Board” estarán enfocadas en la gestión del propio sistema y distinguiremos entre los siguientes tipos: “Agile Coaches”, que se enfocan en la mejora continua y, en particular, en la Agilidad; y “Corporate Angels”, que se enfocan en la función de la propiedad.

Pero volvamos a las conclusiones generales del capítulo dedicado a SDT (Self-Determination Theory), para entender cómo son estas células dentro del ACF. Como hemos visto, para cumplir con las necesidades esenciales para la motivación intrínseca, deberemos buscar Equipos Autónomos Multidisciplinares, que además tendrán un propósito propio. En línea con esto, las características básicas de las células serán por tanto las siguientes:

• Respecto a ser “equipo”, deberá implicar como tal vinculación entre los individuos que lo forman. Es decir, un equipo no es simplemente una selección de un grupo de individuos que ponemos juntos a trabajar. Será equipo cuando se sientan como tal, y para ello quizás sea necesario que evolucionen y se adapten, incluso que tengamos que cambiar, añadir o quitar ciertos individuos que no encajen bien por el motivo que sea. El número de miembros dependerá de cada situación, pero algunos estudios indican como ideal una cifra entre 3 y 9. Obviamente un equipo de 1 no es un equipo y una célula de 2 puede tener más difícil obtener las propiedades adecuadas en cuanto a coliderazgo servil, aunque nada está dicho en ese sentido. Más de 9 miembros parecen generar complicaciones a la hora de tomar responsabilidad de grupo y es aconsejable partir la célula en dos. Obviamente, un equipo depende del talento de los miembros que lo forman. Aunque es cierto que un grupo de futbolistas superestrellas no funciona adecuadamente cuando no forman un buen equipo, del mismo modo un equipo de futbol de torpes tampoco consigue ganar nada. Lo que sí es cierto es que, en cualquier caso, el conjunto predomina sobre las individualidades.

• Para ser “multidisciplinar”, debe aportar en los individuos que lo forman el deseo de ser cada vez mejores en algo que importe para el grupo. Además, el equipo debe ser consciente de sus necesidades en cuanto a maestrías y alertar a la organización dónde se encuentran de sus carencias, buscando bien planes de formación, bien acceso a ellos vía servicios de consultoría o incorporación de nuevos miembros que permitan formar el grupo multidisciplinar apropiado para el fin buscado.

• La condición de ser “autónomo” aportará a los miembros el impulso de dirigir sus vidas. La responsabilidad de las cosas debe recaer en el grupo, no en individuos. De no ser así, el responsable individual de una cosa restaría autonomía al equipo respecto a tomar decisiones en dicha materia. Los líderes por tanto serán serviles, tanto por actitud, como por aptitud en las maestrías que domina. Por otra parte, autónomo no significa, como ya hemos dicho varias veces, independiente. Será autónomo dentro de los umbrales de riesgo y para conseguir un propósito alineado con la propiedad.

• El “propósito” aporta la intención de hacer lo que se hace con el sentido de hacer algo que importa, dando contexto y significado a todo lo anterior. Si formamos un equipo es con un propósito, donde las maestrías que importan son las necesarias para conseguirlo, y donde el equipo es autónomo para decidir el cómo. Pero este propósito tiene que estar alineado con la misión global y con los propósitos parciales, incluidos los del propio individuo, o el sistema no funcionará. Y además deberá encontrarse la forma de cumplirlo añadiendo valor al cliente. Sólo así tendremos una sistema bien alineado y viable.

7.2 La Gestión en la Célula y su Operatividad

Después de lo dicho, la primera posible impresión que nos llevaremos es una Agile Corporation compuesta por un fluido donde las células o equipos de trabajo se mueven libremente adaptándose a su entorno próximo. Y no vamos a llevarle la contraria a Bruce Lee, con su famosa frase “el agua puede fluir o puede golpear” y su célebre final de “be water, my friend”. Sí que podemos decir que entendemos una empresa o corporación Agile como una empresa flexible, moldeable, adaptable, y no por ello exenta de punch, de fortaleza en la consecución de los objetivos. Pero las células de trabajo no son independientes como gotas de agua, sino que en ACF hay reglas, procesos, límites y control, como en la empresa jerárquica. Sin embargo, la diferencia es la gran delegación de parte de este gobierno en la propia célula. Para lograr esto debemos garantizar que la célula está compuesta por personal competente y que funciona como parte operativa del sistema. Esto sólo es así si tiene disciplina y sigue los procedimientos adecuados para ser eficiente y eficaz.

Una de las grandes diferencias con la empresa jerárquica es que una mayor parte de gobierno queda delegada en la célula, lo cual significa que hay funciones de gestión entre sus miembros. Si bien cada individuo tiene un ámbito de gestión tanto en la Agile Corporation como en la empresa jerárquica, en nuestro caso la delegación es mucho mayor en los equipos operativos. Aun así, veremos que existirán células con alta carga de funciones de gestión, compuestas por “Agile Coaches”, que se encargarán de asegurar la operatividad de las células de trabajo, y por “Corporate Angels” que se encargarán de asegurar el alineamiento de las células.

En este punto surge el papel relevante del líder servil, que es aquel que se dedica a resolver las necesidades de otras personas, en vez de preocuparse por lograr ventajas para sí mismo (riqueza, fama, poder, etc.). Así pues, aun siendo líder, su inclinación natural es la de servir, no la de dirigir. Veremos más sobre qué son y cómo son los líderes serviles en el capítulo de gobierno, los cuales emergerán de forma natural en las células ejerciendo su liderazgo en lo que respecta a su ámbito de competencia, a su maestría. Este ámbito podrá ser también el de la propia gestión del equipo, emergiendo como managers en el ámbito de la célula (que también serán serviles).

¿Pero acaso surgen de forma espontánea estas células funcionando perfectamente? Obviamente no. En un momento inicial, las células serán fundadas por los Corporate Angels y a partir de ese momento y según el grado de autogestión, serán ellos mismos, o bien, los Agile Coaches, o los propios miembros de la célula, los que decidirán su evolución para mejorar su operatividad. En cualquier caso, los Agile Coaches deberán efectuar un test de personalidad a la célula, para ver qué diversidad se requiere y si los valores que emergen están alineados con los de la organización. Dicho de otro modo, las células están gobernadas por otras células, conformando un sistema global que aúna agilidad con alineamiento.

En cuanto a su operatividad, una célula de trabajo deberá tener sentido de propiedad sobre su misión de entrega y sobre su propia mejora continua. Es decir, se responsabilizará tanto de su misión alineada con la empresa, como de la mejora de su eficacia y su eficiencia en conseguirla.

Lo hará estando enfocada en el valor a su cliente, sin ligarse con una solución concreta, sino con un enfoque a la acción, trazando hipótesis cuando no posea suficiente información y probando opciones al más puro estilo de Lean Startup. Eso sí, siempre bajo un control de riesgo establecido. A diferencia de una startup, que está a la búsqueda de un modelo de negocio con poco o nada que perder, la empresa o corporación podrá o no estar buscando un nuevo modelo de negocio, pero poseerá ya uno que deberá defender porque será, en mayor o menor medida, el sustento actual de la organización.

Como es bien sabido, en Agile la célula debe incorporar las maestrías que necesite y que sean más críticas, o disponer de acceso a un servicio que satisfaga aquellas que, siendo importantes, no sean tan críticas. Los científicos han determinado que la diversidad puede estabilizar un sistema y hacerlo adaptable a los cambios en el entorno. La diversidad ayuda al sistema a sobrevivir en entornos complicados, incrementa la flexibilidad y genera innovación (según Stacey Engle).

En ACF esta diversidad viene de la mano de los maestros, miembros del equipo que portan maestrías específicas. En un equipo de desarrollo, podría ser el especialista en Arquitectura, el especialista en Calidad del Software (conocido habitualmente como SDET o Software Developer Engineer in Test, al que nosotros preferiríamos denominar Software Developer Master in Test), etc. Su proximidad morfológica con la maestría es aplicable a todo tipo de materias: máster en finanzas, máster en legal, e incluso máster en gestión.

Estos maestros deben alinear la célula con todo lo relacionado con el riesgo y el aprovechamiento de sinergias. Aparte de las funciones que les correspondan como miembros del equipo, los maestros tienen dos funciones añadidas que son fundamentales para el buen funcionamiento del sistema complejo adaptativo. Recordemos la idea general, ser ágil en la capacidad de adaptación, pero encontrar las sinergias que aportan ventaja competitiva a la corporación y no implicar en la operativa un riesgo que la organización no pueda asumir. Para servir de correa de transmisión de estas funciones de alineamiento, los maestros:

• Deben conocer las Paved Roads (Carreteras Asfaltadas) relacionadas con su especialidad que estén disponibles en la organización, con la suficiente maestría como para poder aconsejar al equipo sobre su utilización, pues esto permitirá sacar provecho de las sinergias corporativas, logrando mayor eficiencia.

• Deben conocer el apetito de riesgo de la organización, relacionado con sus funciones, teniendo presente aquellos umbrales de riesgo establecidos como límites. En este sentido, se requerirá su maestría para mitigar los riesgos, con objeto de controlar en todo momento la actividad de la célula, para que sus actividades no impacten negativamente sobre el resto de la empresa o sobre su catálogo de productos.

Pero deberá quedar claro, y el maestro deberá tener siempre presente, que tener una maestría no significará tener una responsabilidad especial o un título específico. Si así fuese, por una parte, las funciones del individuo se verían limitadas a su campo, y por otra se coartaría el análisis por parte de todos de los aspectos clave del funcionamiento de la célula, y ése no es el objetivo. Un maestro, con su maestría y su liderazgo servil, podrá proponer, aclarar, resolver, evitar, diseñar o encargarse de aquello de lo que es especialista, pero el equipo en su conjunto adoptará las decisiones. Para ello, los títulos de los individuos deberán ser lo suficientemente generalistas como para no coartar su ámbito de colaboración; por ello, en el ejemplo anterior el título del individuo seguirá siendo el de desarrollador (software developer), que es como decir miembro del equipo de desarrollo, aunque se añada una etiqueta, como si fuese una insignia de reconocimiento, que especifica que además es un maestro en pruebas (master in test).

Una célula debe maximizar su inteligencia conjunta y para ello debe existir comunicación frecuente y abierta entre sus miembros. En todas las ceremonias y decisiones de la célula debe participar todo el mundo.

Toda célula deberá estar alineada con la organización y para ello deberá estar en contacto con los Agile Coachs y con los Corporate Angels que gestionan su alineamiento y agilidad. Estos dos roles son los protagonistas del modelo de gobierno alternativo al jerárquico que se propone, y también trabajan en células. También en su caso las responsabilidades recaen en células de coaches y de angels, aunque individuos específicos sean los que mantengan las relaciones concretas con las células que deben ser alineadas.

En este sentido, las células siguen un mínimo de especificaciones en cuanto a la transmisión de la visión global a través del corporate angel; el cumplimiento de umbrales de riesgo, mediante los maestros y a través del corporate angel, preservar la cultura Agile en el equipo y tener un compromiso con la entrega de valor, a través del agile coach.

Las células se autogestionan haciendo uso de los artefactos que decidan tener a su disposición, como backlogs de producto, de sprint e incrementos, pero también con otros tipos de artefactos que veremos en capítulos posteriores. Además de los artefactos, usarán ceremonias establecidas, como las de planning, reviews y retrospectivas en el caso del marco metodológico Scrum. Por último, se apoyarán en los recursos que haya a su disposición para su autogestión, así como en las interdependencias que tengan con el resto de la empresa.

La estabilidad de las células es fundamental para que este sistema complejo sea, además de adaptativo, exitoso. Su composición de miembros no se perpetúa, pero sí evoluciona de una forma estable, aunque continua. Sólo así tendrán tiempo para alcanzar su mayor productividad, entendida como aporte máximo de valor. Los coaches y angels les asignarán nuevos productos si tienen capacidad productiva sobrante. Como es obvio, los equipos se construyen cuando existe demanda para su función, pero pueden sufrir reducción de recursos e incluso ser disueltos cuando deja de existir dicha demanda, o por problemas estructurales en su composición.

Finalmente, aplicando Agile al máximo, y por tanto preservando las necesidades esenciales, se garantizará una gran motivación intrínseca de todos los miembros. Pero estos deberán intentar ir más allá, buscando una buena atmósfera, amistosa, divertida y sin estrés.

7.3 Responsabilidades de la célula

Hemos dicho que las responsabilidades recaen en la célula al completo, como equipo, no en los individuos que la componen. Repasemos algunas de las responsabilidades críticas que los miembros de la célula siempre deberían tener presentes.

Podemos empezar por la validez de sus entregas, ya que éstas representan la piedra angular de la Agilidad de Negocio. El primer principio del mismo manifiesto agile establecido en febrero de 2001 está dedicado a las entregas, diciendo que la prioridad más alta del equipo agile deberá ser satisfacer al cliente a través de entregas de valor tempranas y continuas. Estas entregas deberán ser incrementales al final de cada sprint, acordes con lo demandado por el usuario y con el correspondiente valor añadido para el mismo.

También deberán tomar responsabilidad sobre la sostenibilidad del proceso de entregas, pues de nada sirve dar el do de pecho en un primer tramo y relajarse o entrar en problemas de productividad más adelante. Si se alcanza un ritmo de entregas válido para el usuario, con una calidad determinada, las entregas buenas no pueden ser algo excepcional, sino algo habitual.

La agilidad de la célula y su mejora continua deberá significar una filosofía de vida. La célula que decida ser Agile deberá cumplir sistemáticamente con el Manifiesto, con sus valores y sus principios, pero también deberá esforzarse en mejorar de forma constante, sin estancamientos.

Y con esa agilidad y mejora continua, deberá buscar la máxima eficacia de su desempeño. Si la célula trabaja sin descanso, pero sus resultados no llegan a tiempo o llegan sin calidad, de nada servirá la capacidad de trabajo ni la voluntad de intentar hacerlo bien. En caso de que ocurra esto, se deberá efectuar un alto en el camino y revisar las causas raíces del problema.

Las células existen con un propósito alineado con los intereses del accionista, no tienen sentido fuera del ámbito de la organización a la que pertenecen y, por tanto, no pueden ir contra ella. En ese sentido están obligadas al cumplimiento de los umbrales de riesgo. La gestión de riesgo por umbrales es uno de los compromisos más importantes de la célula pues, aunque su trabajo debe ser flexible y autónomo, el resultado del mismo no puede poner en riesgo el resto del catálogo de productos de la empresa bajo ningún concepto, ni la estabilidad de la misma como un todo.

Para finalizar y considerando responsabilidades que indirectamente engloban a todas las demás, la célula deberá siempre buscar un efecto positivo en el sistema. La existencia de la célula y su forma de trabajar deberán ser buenas para el conjunto de células y para la empresa en sí misma. Si esto no es así, habrá que auditar la célula y sus relaciones con las demás, al igual que en el punto anterior.

7.4 Papel del Product Owner de Scrum en la Agile Corporation

Estamos viendo que en ACF todo está organizado en células. ¿Qué pasa pues con uno de los roles más típicos de agile, el product owner (PO), que tan importante papel tiene en Scrum? Scrum es hoy en día el marco metodológico agile más extendido.

En el ámbito de Scrum, podríamos resumir diciendo que el PO es el responsable del “qué”. En esta especie de superhombre recae la responsabilidad de maximizar el valor del resultado de la célula de desarrollo. Trabaja solo, ni siquiera en comité, y es el responsable de la gestión del backlog de producto, el cual incluye los elementos del backlog, propuestas independientes de valor añadido para un producto bien rebanado, que estarán ordenadas para lograr su objetivo, optimizando el valor del esfuerzo de trabajo del equipo de desarrollo. El PO asegurará la visibilidad de este backlog y su entendimiento por todos.

Por otra parte, Scrum apunta que el PO sólo tendrá éxito si la organización le respeta a él y a sus decisiones, con lo que además de un poco de superhombre, tiene un poco de dios, cuya voluntad parece no tener límites, excepto en la cuestión de no poder forzar al equipo de desarrollo a trabajar en los requerimientos en el preciso orden y con la prioridad que él ha establecido en el backlog de producto.

Podríamos considerar al PO del marco de trabajo Scrum como una célula de ideación de un solo miembro, pero sería como hacer trampas. El product owner tiene una alta carga de trabajo conceptual y creativo. Además, incluso en una empresa mediana, se ve difícil que alguien pueda conducir sólo, sin la ayuda de un equipo, la definición y estrategia de un producto. ¿Y cómo encaja este modelo con las técnicas de design thinking, que tan ágiles nos parecen, pero que están diseñadas para grupos de trabajo? La creatividad y la innovación en la era moderna es cosa de equipos, no de superhombres. Es cierto que puede existir un visionario que marque una idea, una estrategia, una visión, pero luego hará falta un equipo trabajando de forma coordinada, siguiendo un proceso creativo determinado, abarcando las maestrías necesarias para que dicha innovación o creación tenga finalmente efecto.

Por tanto, en agilecorporatipon.org nos gusta ver al PO como a un miembro más de un equipo de trabajo de ideación. Debería constituirse como tal, como célula de ideación. Lo más probable es que de este equipo de ideación surjan elementos que deban ser desarrollados por distintas células de trabajo. Unos equipos tendrán que trabajar en el desarrollo de software, otros en las campañas comerciales para su puesta a la venta, otros deberán implantar los cambios de procesos en las operaciones, etc.

Para nosotros, puede ser que exista más de un PO en esa célula de ideación. Esos PO además no serán responsables únicos del producto, pero sí tendrán la función de alinear los propósitos de las células de desarrollo (desarrollo de SW, de procesos en operaciones, de campañas comerciales, etc.) con el propósito común y global relacionado con el producto. Para ello, estos PO deberán desempeñar funciones como las descritas en la Scrum Guide de la Scrum Alliance, que hemos adelantado anteriormente, porque buscará maximizar el resultado del equipo de Desarrollo que le ha tocado “coordinar”. Y aunque recaiga en un solo PO la función de alinear cada equipo de producto, no será el responsable único del backlog de producto, pues esto recaerá en la célula de ideación.

Su gestión del backlog de producto que corresponde a su célula de desarrollo incluirá, al igual que ocurre con el PO del Scrum Alliance:

• Expresar de forma clara los elementos del backlog que el equipo de Desarrollo deberá trabajar.

• Ordenar dichos elementos lo mejor posible para conseguir el propósito global, con el cual debe alinearse el equipo de desarrollo.

• Optimizar el valor del trabajo que desarrolla el equipo de desarrollo que él coordina.

• Asegurar la visibilidad, transparencia y claridad del backlog de producto para todos, dejando que se vea a qué debe dedicarse el equipo.

• Asegurar que el equipo de desarrollo entiende los elementos del backlog al nivel requerido.

Pero, a diferencia de lo propuesto por la Scrum Alliance, el product owner no trabaja solo, no define la estrategia solo, no determina las prioridades solo. Sin embargo, es el representante de la célula de ideación que tiene la función de alinear ese equipo de desarrollo concreto. Y las decisiones que dicha célula tome, tendrán que estar sujetas a los mismos criterios descritos y enumerados anteriormente, es decir, deberán respetar los umbrales de riesgo, y deberán alinearse con los intereses de la organización, coordinándose con los agile coaches y los corporate angels correspondientes.

7.5 Coexistencia con la Empresa Jerárquica

Dicho todo esto, el product owner al estilo de Scrum Alliance es una pieza fundamental para integrar células agile independientes dentro de la empresa jerárquica. Tal y como se describe, él puede retener la responsabilidad sobre el producto como parte final de una jerarquía establecida que sirve de correa de transmisión de los intereses de la propiedad.

Por otra parte, las células Agile de que dispongamos en la corporación deberían cumplir en la máxima medida lo expuesto en este capítulo. Ya se trate de equipos Scrum, de equipos Kanban, o bien, aunque apliquen modelos específicos diseñados por la corporación, es lógico que todos ellos sean compatibles con la Agile Corporation si asumen los valores del Manifiesto Agile y si cumplen sus principios. El problema suele estar en la integración de estas células dentro de la empresa jerárquica. En ese sentido, Jurgen Appelo, en su libro Management 3.0, da las claves de cómo hacerlo.

Antes de nada, deberemos desarrollar o disponer de lo que él llama “líderes agile”, responsables de estos equipos que entienden todo lo dicho respecto a la self determination theory y los sistemas complejos adaptativos. Estos líderes sabrán respetar al máximo la autonomía de sus células y les transmitirán que su propósito es cumplir con lo que determina el PO. En realidad, estos líderes Agile se parecen un poco a lo que en ACF llamamos corporate angels, excepto en que, al igual que el PO, también están concebidos como parte de la estructura jerárquica.

Hay un tercer rol que normalmente encontramos en las empresas grandes que aplican agile, y que también es necesario para una correcta integración: el agile coach o el scrum master. Nuevamente, podríamos encontrar similitud de éstos con los agile coaches de ACF, excepto en que los propuestos por agilecorporation.org también trabajan en células y se alinean de forma especial.

Resumiendo, la integración de ACF a nivel de célula en la empresa jerárquica es relativamente fácil y coincide en gran medida con las prácticas que encontramos en las empresas de hoy que quieren hacer Agile. Sólo es preciso reseñar dos cosas: la falta de líderes agile al estilo Management 3.0, los cuales son fundamentales para que estos equipos funcionen bien y que, en cualquier caso, hablamos de un modelo en el que las células Agile pueden sobrevivir, contra los vientos y las mareas procedentes de la estructura jerárquica en la que se integran. Si bien es una forma de encapsularlas contra los efectos del medio hostil en el que operan, obviamente la propuesta de agilecorporation.org es cambiar dicho medio hostíl por un medio que favorezca la agilidad, pero ese es precisamente el valor diferencial que pensamos que ACF aporta y lo iremos viendo en los próximos capítulos.

Mientras la empresa decide dar este paso importante, el de pasar de “hacer” agile, a “ser” agile, desde ACF recomendamos que se mantenga la cercanía entre estas células en la medida de lo posible, tanto organizativa como físicamente.

8 Sobre su Escalado y Complejidad

8.1 Objeto del Capítulo

Una vez analizada la complejidad de las células, éstas también se interconectan entre sí mediante interdependencias, formando estructuras más complejas en las que emergen nuevas funciones que, en una escala superior de complejidad, también necesitamos analizar. Es decir, una vez entendido el funcionamiento de las células, nos abstraemos de la complejidad de su interior para ver que ellas mismas forman estructuras superiores, centrándonos entonces en cómo éstas se comportan dentro de la estructura a la que pertenecen.

Dichas interdependencias se crean mediante artefactos y ceremonias. Podemos decir que una interdependencia es la acción de ser dependiente, responsable y de compartir, desde la autosuficiencia, algo con otra célula. Aunque las interdependencias existen siempre, es bueno documentarlas y analizarlas porque ello nos permite valorar la pérdida de agilidad y ganancia de alineamiento, reajustando el funcionamiento en caso de que este balance resulte negativo.

En este capítulo estudiaremos los mecanismos y herramientas de que dispone la corporación para escalar el modelo de agilidad a toda su organización, teniendo en cuenta la necesidad de gestión de la complejidad intrínseca en la empresa.

8.2 Introducción a las interdependencias

Decíamos que las interdependencias existen siempre, tanto si documentamos su existencia como si no lo hacemos, pero que ponerlas de manifiesto y documentarlas facilitará la propia comunicación entre los gestores que participen en el gobierno, de forma que les será más fácil identificar mejoras en el sistema.

Lo más importante que debemos tener en cuenta respecto a las interdependencias es que:

• Permiten la colaboración entre las células o entre los individuos, y por tanto el alineamiento de sus propósitos.

• Reducen el grado de libertad y agilidad de la célula ya que necesitan coordinarse con otra célula a la hora de perseguir su propósito.

Entrando en cómo son y cómo funcionan, diremos que siempre se componen de:

• Al menos un artefacto. Herramienta o pieza de información o de “producto” que se comparte entre células o individuos.

• Una Ceremonia. Acto reglado entre células o individuos que, haciendo uso de los artefactos, sostiene una interdependencia.

Los artefactos permiten transparencia entre los elementos que se relacionan. Si hablamos de interdependencias dentro de una célula, entre sus individuos, estas piezas de información o herramientas son el elemento de consenso alrededor del cual se produce la alineación entre las partes. Si hablamos de relaciones entre células, funciona de igual manera. La forma de gestión del artefacto dependerá de cada caso, pero obviamente deberá estar consensuado entre las dos células y su seguimiento quedará reflejado en la ceremonia, de la cual hablaremos a continuación. Tomando la metodología Scrum como ejemplo, serían artefactos los backlogs de producto, los backlogs de sprint y los incrementos de producto, todos ellos usados como interdependencias entre los individuos de la célula, así como entre el Product Owner y la célula. Fuera del marco Scrum, podríamos decir que un informe de seguimiento o un cuadro de mando son artefactos. Podríamos seguir enumerando ejemplos de artefactos, pero por el momento nos basta con este conjunto para continuar con nuestro análisis.

Las ceremonias son actos reglados entre células o individuos que, haciendo uso de los artefactos disponibles, sostienen la continuidad de una interdependencia. Quien participe en la ceremonia dependerá obviamente de cada caso. Si hablamos de alineamiento entre individuos de una célula, como podría ser el caso de una ceremonia para gobernar la mejora continua, sólo éstos participarán en ella. Si hablamos de relaciones entre células, podrá darse el caso en el que participen todos los integrantes de una de ellas y un representante de la otra, caso probable cuando la ceremonia es de alineamiento de desarrollo de producto entre una célula de desarrollo y el representante de la célula de ideación. Pero también puede funcionar con un subconjunto de miembros de ambas células, como pasaría en una ceremonia orientada a planificación estratégica. No podemos dejar de mencionar ceremonias donde participen miembros de más de una célula, lo cual también es posible, ya que una interdependencia puede alinear varias células. Continuando con el mismo ejemplo de la metodología Scrum, las ceremonias serían los dailies para inspección diaria del avance dentro del equipo y planificación del siguiente día, los sprint plannings, donde el equipo se alinea con el product owner para la planificación del siguiente sprint, los sprint reviews, donde para inspeccionar el incremento del sprint también se invita al usuario, o las retrospectivas, ejemplo similar al de la mejora continua descrito anteriormente. Al igual que en el caso de los artefactos, probablemente podríamos enumerar muchos más ejemplos, pero entendemos que estos son suficientes para hacerse una idea.

¿Y qué hay de nuevo en esto que estamos diciendo? ¡Todos los ejemplos mencionados existen ya en la actualidad!

Los lectores conocedores de Scrum entenderán que la relación entre un product owner y la célula es muy diferente a la jerárquica entre un jefe de proyecto y su equipo. Lo mismo pasa entre este equipo y el Scrum Master. Tampoco él es el “jefe” del equipo. El esquema ideal del marco Scrum es que la célula no tiene jefe. Jurgen Appelo, en Management 3.0, ya nos habla de los líderes agile, que son los líderes que, sin ser “jefes”, gestionan la célula. Nuestro modelo propone que sea el esquema organizativo el que permita gestionar células sin “jefes”, y con gestionar nos referimos a alinear su propósito, a asegurar su productividad, a resolver los problemas personales de sus miembros como empleados, etc. Los líderes serviles son eso, líderes que aparecen de forma natural, no porque alguien en la organización los nombra, y cuya influencia es tan compleja y tan ágil como son el sistema que representa la empresa y su supuesta agilidad para adaptarse al entorno cambiante.

Por tanto, aunque los artefactos son elementos ya conocidos por todos nosotros y las ceremonias también, la diferencia estriba en lo que representan y cómo se gestionan. En cualquier caso, es importante entender este elemento básico de la complejidad del sistema para poder visualizar una empresa como sistema complejo adaptativo, con elementos muy autónomos, con estructuras nada jerárquicas, pero alineando esa capacidad de adaptación para perseguir un propósito común que cumple con los intereses de la propiedad. Y mientras visualizamos esto, tengamos presentes varios puntos:

• Hay mecanismos de gobierno y organizativos específicos de este modelo que facilitan su funcionamiento.

• Concebimos la transformación como algo gradual partiendo de un ecosistema pequeño pero perfectamente integrado, el AEZero, que irá creciendo para convertirse en la AEZone, siempre bien integrado en la empresa jerárquica, que irá dejando de serlo conforme esta AEZ crezca y vaya suponiendo la mayor parte de la empresa.

8.3 Efecto de la existencia de interdependencias

Algo a destacar y que vamos mostrando en este libro, es que hay relaciones que se establecen sin estar formalizadas. Hablamos de relaciones entre individuos, pero también de interacciones entre equipos. Cuando decimos que no están formalizadas nos referimos precisamente a que no hay una ceremonia preestablecida, o un artefacto acordado. La propia cercanía entre los miembros de un equipo favorece la coordinación y la comunicación, sin que sea necesaria una sesión programada con tal propósito. La existencia de una intranet donde se comparta información de la empresa tiene un efecto similar. En realidad, la interdependencia es la formalización de una relación existente entre dos partes de un sistema, ya sea espontánea, que emerge de forma natural, o forzada por los gestores del sistema. No debemos caer en la ilusión de que toda comunicación en el sistema ocurre a través de las interdependencias identificadas o documentadas, donde hemos establecido el artefacto y las condiciones de su ceremonia. Sería prácticamente imposible intentar documentar todas las relaciones de comunicación que se pueden dar en un contexto dado, por ejemplo, aquellas que surgen por afinidad personal, por actividades extralaborales, o simplemente por casualidad.

Por tanto, tenemos por una parte que las interdependencias forzadas disminuyen la agilidad en mayor o menor grado según lo apropiadas que sean, no obstante, nos permiten alinear la célula con los objetivos globales. Por otra parte, las interconexiones libres tienen la ventaja de que normalmente no limitan la agilidad del sistema a la vez que fomentan el alineamiento, aunque no lo aseguran. Esto nos hace pensar que deberíamos impulsar en la organización mecanismos que fomenten las interdependencias libres, pero como vamos a ver no siempre parece lo correcto. Por lo general, hay que decir que cualquier comunicación que surja entre partes del sistema será beneficiosa, y de ahí la potencia del equipo de trabajo que comparte espacio físico y tiempo. Sólo deberíamos preocuparnos de documentar y analizar aquellas comunicaciones que se establezcan de forma estable, con un control, un alineamiento o una función de gobierno. Las comunicaciones de este tipo restarán agilidad, por lo que deberemos analizar si aportan valor y si son necesarias para el alineamiento de las partes.

Por último, escribimos este libro en tiempos de confinamiento debido a la COVID-19. Esta pandemia está haciendo cambiar el mundo que conocemos, pero también algunas ideas preestablecidas. Veíamos como una idea generalizada entre los profesionales Agile que precisamente esta proximidad entre individuos de la célula era casi imprescindible, o que su falta perjudicaba mucho la agilidad. Recordemos el primer valor del manifiesto: priman las relaciones interpersonales sobre herramientas y procesos. Nuestra apreciación actual, tras unos meses de experiencia forzados a trabajar en equipos cuyos miembros estamos confinados en nuestras casas, haciendo uso de plataformas de videoconferencia es que, por una parte, la agilidad de las células ya maduras es más resistente de lo que parece. Por otra parte y para evitar el caos, en equipos no muy agile ha surgido por necesidad la implantación de ceremonias regladas. Es decir, la interdependencia gestionada resta agilidad, pero al mismo tiempo fortalece la agilidad remanente. Y cuando una organización es consciente de la posibilidad del desalineamiento, cosa que pasa continuamente sin percibirse, recurre a la nueva interdependencia con frecuente éxito.

Vamos a profundizar un poco más en cómo las interdependencias coartan la agilidad, pero mejoran el alineamiento, y cómo deberíamos trabajar para que se minimizara el impacto en lo primero y se maximizara en lo segundo. Por ejemplo, el backlog que la célula de ideación crea para coordinarse con la célula de desarrollo coarta la libertad de ésta última en su elección del propósito, el cual tendrá que estar alineado con dicho backlog. De no tener interdependencias, las células serían más ágiles, pero el sistema en su conjunto sería un caos. Por tanto, podemos decir que las interdependencias hacen viable que un conjunto de células funcione como una organización Agile. Dicho esto, deberemos cuestionarnos constantemente si podemos permitirnos el lujo de eliminar una interdependencia para ganar agilidad o si, por el contrario, tenemos que establecer alguna nueva interdependencia para reducir el caos.

Es muy normal que cuando empecemos a hablar de transformar una empresa en una organización agile surja el tema de la cultura. Sabemos también que la gestión del comportamiento es una herramienta importante a la hora de cambiar la cultura. Es necesario que la persona reaccione y se comporte de una forma distinta si queremos que acepte el cambio en lugar de aferrarse a un plan, o que ponga siempre foco en aportar/entregar valor al cliente en lugar de enfocarse en sí misma y resolver sus propios problemas. Es obvio también que cuando tenemos una interdependencia, la forma de actuar de un individuo o de una célula a un extremo de ella, dependerá del comportamiento de la otra parte, o partes, ya que recordemos que una interdependencia puede afectar a varios agentes. Por tanto, podemos llegar a la conclusión de que, moldeando interdependencias, a través de reconfiguración de sus artefactos o configuración de sus ceremonias, también podemos moldear comportamientos. Esto es una generalización del dicho “métricas moldean comportamientos” tan usado en ámbitos agile, ya que una métrica o conjunto de indicadores es al fin y al cabo un ejemplo de artefacto.

Como ejemplo de lo anteriormente expuesto, debemos hacer mención de una interdependencia especial, aquella que se establece entre los maestros y un área de expertise. Como son dos conceptos aún no explicados en detalle, hagamos una pequeña introducción al problema en cuestión: ¿cómo podemos hacer que las células se alineen usando los servicios internos y cumpliendo los controles sin romper su autonomía? A esos servicios internos, gestionados y ofrecidos de forma diferente, más amistosa con las células agile, los llamamos carreteras asfaltadas o paved roads, y a los controles, gestionados e implantados dejando más espacio de maniobra a los equipos los llamamos gestión de riesgos por umbrales o risk threshold management. Pero por ahora imaginémonos simplemente servicios internos y controles tal y como los conocemos.

Considerando que un maestro es un miembro de la célula que tiene una maestría específica, es decir, que conoce o domina una determinada materia, una forma de moldear el comportamiento de la célula es generando una interdependencia entre este individuo, miembro del grupo que lidera esas materias, y el área de expertise o departamento de la empresa que proporciona los servicios internos o controles relacionados con la materia que domina. Haciendo colaborar o participar al maestro en la definición de los servicios o diseño de los controles, o asistiendo a mesas redondas o seminarios dirigidos a tal fin, podremos motivar al maestro a que lidere su equipo en favor del alineamiento global. Esto ya es práctica común en muchos sitios, pero en nuestro modelo esto forma parte del modelo de gobierno, no simplemente como una actividad en pro de un bien general. Y como parte del gobierno, su implantación debe ser bien estudiada en su forma y fondo de manera que, una vez más, la implementemos maximizando el alineamiento, pero preservando al máximo su agilidad.

8.4 Diversidad de las interdependencias

El número de posibles tipos de interdependencias es enorme. Según el tipo de función que busquemos, deberemos idear y definir una interdependencia de una naturaleza concreta en cada caso. Así pues, las distintas partes de la empresa tendrán funciones diferentes y, por tanto, requerirán interdependencias diferentes, con artefactos y ceremonias específicos en cada caso.

Son ya clásicas las interdependencias sugeridas por las Metodologías Agile aplicadas al desarrollo de software, ya mencionadas anteriormente. En nuestro caso, al extender el modelo Agile a la globalidad de la empresa, vemos la necesidad de proponer nuevos artefactos y ceremonias. Estas propuestas serán meros ejemplos que deberán adaptarse a las situaciones concretas de cada una de las empresas (una vez más, no hay soluciones estándar y generalistas para todas las situaciones).

En primer lugar, analicemos los diversos tipos de artefactos, entrando en detalle en algunos de ellos. Debemos tener en cuenta lo siguiente a la hora de diseñarlos:

• Son herramientas o piezas de información puestas en común por los agentes con el objetivo de transparentar algo y facilitar su inspección, motivando a partir de ahí la adaptación al nuevo estado (los tres pilares de Scrum, pilares que hacemos también nuestros). Por tanto, deben estar disponibles y ser visibles y accesibles.

• Modelan el comportamiento de los actores que los usan y, por tanto, el funcionamiento del sistema. A la hora de definir o implantar uno, debemos analizar y considerar su impacto.

• Dicho lo anterior, deben ser sencillos y claros. Lo que menos vamos a querer es que generen confusión. Mientras más complejo sea un artefacto, más abierto estará a la libre interpretación.

Ya hemos dado ejemplos de artefactos, empezando por los propios de Scrum: backlog de producto, backlog de sprint, e incremento de producto. Otros ejemplos pueden ser las herramientas que la Universidad de Stanford propone para los procesos de design thinking, o el conocido Cuadro de Mando Integral. También tenemos que considerar artefactos, aunque algo especiales, a los usados en técnicas de gamificación, como las insignias, que podríamos usar en forma de certificaciones de maestría, o los rankings, publicando indicadores de agilidad de la célula.

Por ver más de cerca uno de estos artefactos, vamos a usar de ejemplo el “Cuadro de mando de umbrales de riesgo”. Su uso está destinado a hacer ver a las células en qué grado están cumpliendo los umbrales de riesgo establecidos. La idea es que, por debajo de ese umbral, la decisión de cómo operar es de la propia célula, pero por encima de ese umbral se considera que la célula puede estar poniendo en riesgo al resto de la compañía. El artefacto podría ser un esquema temporal de cómo la célula ha estado incumpliendo dichos umbrales y la gravedad con la que los ha sobrepasado. Se utilizará una representación cualitativa (usando colores, por ejemplo) que se calculará a ser posible de forma cuantitativa, y en cualquier caso de forma objetiva. Si el equipo está en verde, no se informará sobre el indicador cuantitativo subyacente ya que, una vez por debajo del umbral, no buscamos que bajar dicho indicador se convierta en propósito del equipo, el cual debe estar enfocado en incrementar valor al cliente. No buscamos equipos campeones de este indicador, sino equipos autónomos que no sobrepasen el umbral definido.

Otro ejemplo de artefacto puede ser el “Cuadro de interdependencias de producto”, utilizado con objeto de transparentar dependencias entre distintas partes del desarrollo del producto. Podría ser una tabla donde se especificara el elemento de dependencia, quién lo requiere, fecha estimada de la necesidad (según el backlog de dicha célula), célula que lo provee, fecha estimada de entrega (según el backlog de dicha célula), impacto, o información sobre alternativas de resolución y daños producidos. Esta sería una forma de transparentar las relaciones causa-efecto entre los desarrollos de los equipos, todos ellos alineados hacia un propósito común de aportar valor al cliente.

En cuanto a las ceremonias, esos actos reglados entre células o individuos que, mediante los artefactos, sostienen la continuidad de una interdependencia, deberemos tener en cuenta lo siguiente a la hora de diseñarlas o implantarlas:

• Deben ser sencillas y livianas. Los equipos no pueden tener la sensación de estar perdiendo el tiempo en ellas. Deberán estar invitados sólo aquellos miembros que tengan que aportar o recibir de la ceremonia.

• Crear o diseñar ceremonias es una forma de modelizar las interdependencias y por tanto el funcionamiento del sistema. Por tanto, determinemos bien su propósito y sus reglas (objetivos, lugares, tiempos, mecanismos de intervención, interrupciones, etc.).

• Antes de crear una ceremonia nueva por necesidad, debemos analizar si una ya existente puede sostener igualmente la nueva interdependencia, pues reducir la complejidad en el entendimiento del sistema puede ser beneficioso casi siempre.

Aparte de las mencionadas ceremonias de Scrum (daily, sprint planning, review y restrospectiva), podríamos considerar ceremonias los ciclos de ideación, sesiones formativas, concursos de innovación, comités de gobierno o seguimiento, sesiones de coordinación de producto y muchas otras. La condición para que sea ceremonia según nuestro criterio es que tenga un propósito concreto, una periodicidad prefijada, unas características negociadas con los participantes, y que estén soportadas por uno o varios artefactos que garanticen la continuidad del avance del propósito ceremonia a ceremonia. Es decir, mientras que la ceremonia garantiza y da continuidad a la interdependencia, creando una disciplina para reunirse y alinearse ante un propósito, para hacerlo de una forma continua y con sentido necesita al artefacto sobre el que se basa.

Para ver qué pinta tiene una ceremonia a nuestro parecer, veamos como ejemplo las Sesiones de Coordinación de Producto, las cuales serían necesarias sólo para coordinación de actividad de productos muy complejos. La misión de estas ceremonias sería alinear las prioridades de backlogs que, encontrándose lejos en la estructura de células de producto, mantengan una dependencia entre uno y otro sobre un elemento de desarrollo. De esta forma se eliminaría cualquier obstáculo para el progreso de la entrega de valor al cliente. En ellas participarían la célula de ideación de primer nivel, es decir, la que marca la estrategia global del producto, o bien una célula específica creada para esta función en el caso de tratarse de productos muy complejos. También estarían invitados representantes de las células que proveen o requieren alguno de los elementos que tienen en común y sobre los cuales es necesaria una coordinación. Finalmente, podría ser requerido por la célula que organiza la ceremonia algún representante de las células de coaches y angels que dan soporte a ambas células de producto. Las primeras para asegurar la agilidad del conjunto, las segundas para asegurar el alineamiento.

Otro ejemplo de ceremonia podría ser el Comité de Gobierno de la Agilidad, cuya misión sería eliminar cualquier obstáculo para el progreso de la agilidad en la empresa, proporcionar feedback a las células de primer nivel del agile board y agile coaching sobre la consecución de mejoras en la agilidad, priorización de las medidas programadas para la mejora de la agilización, y proposición de mecanismos que incentiven nuevas ideas. En ella deberían participar los individuos seleccionados por las células de Agile Board y Agile Coaching de primer nivel, así como miembros seleccionados por las células de primer nivel de los productos considerados más críticos y de las áreas de expertise más importantes. Para esta ceremonia, muy necesaria en una empresa que decida transformarse, la situación de partida sería constituir una ceremonia reducida donde estén participando el primer miembro del agile board y el primer miembro del agile coach. También deberían participar los directores de los productos más críticos que decidan migrar a Agile, así como los directores de las áreas funcionales que decidan convertirse en áreas de expertise. El propio comité de gobierno de la agilidad decidirá añadir más miembros al comité o su subdivisión en varios comités cuando en el caso de una corporación sea necesario.

Para finalizar este apartado sobre el efecto que tiene la existencia de interdependencias, diremos que éstas, tanto las libres como las forzadas, forman nuestra Red Neuronal Interna (neural network) para el gobierno del sistema. Podemos suponer, por tanto, que a mayor número de interconexiones se produce mayor comunicación, más rica es nuestra red neuronal, y dotamos al sistema de mayor inteligencia.

Pero esta inteligencia también dependerá de la adecuación de la estructura de comunicación, y no sólo del número de interconexiones. Nuevamente nos encontramos con que no existe una estructura buena para dos casos distintos. Cada sistema, cada subsistema, requiere una estructura específica. Si la estructura emerge de forma natural en el sistema, aunque luego la documentemos y analicemos, será más probable que sea la correcta para ese caso en particular, con la menor merma de agilidad posible.

La cuestión es que se requieren interdependencias entre individuos para conseguir que una célula funcione de determinada manera. También se requieren interdependencias entre células para conseguir que funcione un equipo de producto persiguiendo un propósito común. Deberíamos ver estas interdependencias como la red neuronal por la que se canalizan los alineamientos desde la célula de ideación a la de desarrollo y las aportaciones de valor en sentido inverso.

8.5 Tipos de Interdependencias en ACF

Ya hemos hecho referencia durante este capítulo a dos tipos de interdependencias, las forzadas y las libres. A las primeras las vamos a llamar “gestionadas” a partir de ahora, ya que en puridad pueden tratarse dependencias existentes en un principio de forma natural y que queramos moldear. Por ello, a partir de ahora hablaremos de dos tipos principales: las gestionadas y las no gestionadas. Ambas deben analizarse por separado porque su aportación al modelo, a la gestión global de la organización agile, es diferente.

Para analizar las gestionadas las subdividiremos a su vez en dos: Las interdependencias dirigidas al ecosistema agile, lo que llamamos AEZ, y que gestionaremos con los artefactos y ceremonias del tipo que hemos hablado, en favor de los patrones que busquemos; y las interdependencias del gobierno ya establecido en la empresa (del gobierno anterior a la transición hacia la agilización), las cuales pueden estar fuera de nuestro control, pero inevitablemente afectarán también al ecosistema agile, el cual se encuentra intregrado en la empresa jerárquica.

Las no gestionadas, o libres, también las vamos a dividir en dos: Las interdependencias improvisadas o libres con el exterior (con clientes, con proveedores, con la sociedad), las cuales podrán ser moldeadas por el propio proceso adaptativo convirtiéndolas en gestionadas; Y las interdependencias derivadas de la cultura, difíciles de gestionar, ya que no están escritas ni son evidentes. Ya dijimos que el sistema modela la cultura y que para cambiar la cultura deberemos cambiar el sistema. En un comienzo, estas interdependencias serán las propias inspiradoras o motivadoras de la cultura de partida. Conforme vayamos transitando hacia un sistema más ágil, la propia cultura y las interdependencias derivadas irán transitando también. No vamos a considerar interdependencias a las relaciones entre individuos o entre equipos que sean fútiles o esporádicas. Para considerar estar relaciones como interdependencias deberán tener algún comité establecido o algún proceso de reporte que las haga continuas y que perduren en el tiempo.

Una vez desgranadas las interdependencias en estos cuatro grupos, pongamos foco primero en las gestionadas dirigidas a la AEZ. Si bien todo tipo de interdependencias son importantes, hay que considerar que éstas son el futuro del sistema. Por lo tanto, habrá que diseñarlas de acuerdo con la gestión y la cultura que queramos fomentar.

Estas interdependencias serán las que reinen en la AEZ, pero aquellas que veamos fáciles de implantar a nivel global y que no contravengan la cultura y la gestión de la organización, deberíamos proponer implantarlas a nivel global, no sólo en la AEZ. Hay que tener en cuenta que si la organización está implantando la AEZ será porque cree en los valores agile, y estas interdependencias favorecerán patrones que faciliten la transición hacia la agilidad de forma natural en toda la organización.

A este primer grupo pertenecerían algunas interdependencias como el alineamiento de los posibles propósitos que persiga un equipo de trabajo, el alineamiento de la visión de producto (roadmap) entre células de distinto nivel en el equipo de producto, la coordinación entre equipos de grandes productos sin interdependencias directas, la promoción de la innovación dentro del equipo de producto, o la búsqueda de ventaja competitiva por parte de todos los equipos

Respecto a las interdependencias del gobierno ya establecido, que consideraremos nuestro segundo grupo, de las que podemos encontrar fácilmente ejemplos como controles sobre procesos de compras, auditoría interna, relación del personal con RRHH o gestión presupuestaria, será importante catalogarlas y buscar analogías con artefactos y ceremonias para entender mejor su funcionamiento, a la vez que buscar alternativas que puedan ser válidas para su aplicación en la AEZ, y pasen a formar parte del primer grupo. En cualquier caso, éstas afectan a toda la globalidad de la empresa y lo normal es que podamos hacer poco al respecto.

Lo que si necesitaremos es librar a la AEZ de su influencia en el caso de que sean muy restrictivas. Para ello el gobierno de la empresa deberá exonerar a la AEZ de su cumplimiento, definiendo otras del primer grupo que persigan el mismo objetivo. Otra opción es buscar su adaptación, de forma que, cumpliéndose el propósito para el cual fueron creadas, se lleven a cabo en la AEZ de manera que salvaguarden su agilidad.

El tercer grupo para nosotros son las interdependencias con el exterior. También en este caso será muy importante catalogarlas y buscar analogías con artefactos y ceremonias para entender mejor su funcionamiento. Si la relación es entre el exterior y la AEZ, deberán pasar a ser gestionadas, como las del primer grupo, independientemente de si se trata de relación con clientes, proveedores o cualquier otro stakeholder. Si se trata de relaciones entre partes de la empresa fuera de la AEZ con el exterior, no debemos por el momento preocuparnos de ellas. Evolucionarán de forma natural con el resultado de los procesos de agilización conforme la AEZ crezca, lo cual será positivo tanto para el equipo interno como para su contraparte, ya sea el cliente, el proveedor, etc.

El cuarto grupo, las asociadas a la cultura general de la empresa pero que no son fruto de comités o controles específicos, normalmente están ocultas y obedecen a mecánicas de motivación extrínseca y a reglas sobreentendidas, aunque no escritas. Nuevamente, la forma de proceder es identificar dichas mecánicas o reglas no escritas y sacarlas a la luz para poder comprender el funcionamiento del sistema. Será importante catalogarlas con base en los patrones que percibimos en la empresa actual, en su cultura, blindando la AEZ frente a aquellas que promuevan una cultura muy contraria a la nueva perseguida por la propiedad para transformar la organización, aumentando su agilidad. Esto es más complicado al tratarse de interdependencias no gestionadas.

8.6 Ejemplos de Interdependencias

Para empezar, pondremos ejemplos de Interdependencias entre células de producto (interno o externo), es decir, entre aquellas células que conforman el equipo de producto, ocupándose cada una de ellas de una parte específica. Para ello deberán alinear la visión de producto entre células de distinto nivel.

El típico artefacto para esta labor es el backlog de producto de Scrum y sus incrementos. El primero es una lista de elementos de mejora propuestos, priorizados según el orden en el que aparecen. Cada elemento debe representar una aportación de valor tangible. Las ceremonias típicas para ello también serán las de Scrum, con los sprint planning y reviews de incrementos entre las dos células. Es decir, básicamente estamos exponiendo el modelo Scrum pero con un matiz relevante, que en lugar de aplicarse entre un product owner y una célula, se hace entre dos células, aunque en la práctica la célula de ideación lo haga a través de la figura del product owner. Podríamos resumir la sutil diferencia en que el product owner no es el único responsable del backlog de producto, sino que toda la célula de ideación lo es.

Intentando huir de ejemplos muy ligados al modelo Scrum, podemos tratar otro ligado al artefacto ya descrito como ejemplo más arriba de “Cuadro de interdependencias de producto”, utilizado para la coordinación entre equipos grandes de producto, formados por varias células y con interdependencias indirectas. Al artefacto mencionado habrá que asignarle unas ceremonias. La más importante sería la del “ciclo de ideación”, entendida como el cierre de un proceso de design thinking. En ella, las células que identifiquen dependencias con desarrollos llevados a cabo en otras células lo notificarán a su célula de coaches. Éstas añadirán la dependencia al artefacto, el cual será revisado en otra ceremonia, las Sesiones de Coordinación de Producto, también descrita ya como ejemplo de ceremonia anteriormente.

Otras interdependencias orientadas a producto que nos parecerían interesantes de crear en cualquier empresa agile son:

• La que garantice la mejora continua de la eficiencia y eficacia de la colaboración entre células, utilizando como artefacto el de “elementos de mejora propia” para cada célula, y una ceremonia conjunta entre miembros representantes de cada célula.

• La que fomente la innovación interna del producto, usando como artefactos las propuestas de ideación con prototipado Lo-Fi e incrementos y las ceremonias de planning y reviews de la célula de ideación, con participación de miembros representantes de la célula de desarrollo.

Siguiendo con ejemplos concretos, veamos algunas interdependencias entre las Células de Producto y de Gobierno que nos parecen interesantes para garantizar el alineamiento de todas las partes con la propiedad:

• La que garantiza el alineamiento de la visión de producto con la visión de la empresa, basada en los clásicos artefactos de Scrum de backlog de producto e Incrementos. Las ceremonias también serían las mismas de Scrum, planning y reviews de incrementos, pero en este caso sugerimos la colaboración (y en cierta medida supervisión) de los angels.

• Podemos revisitar la interdependencia vista más arriba de mejora continua de la eficiencia y eficacia de las células, con los mismos artefactos y ceremonias, pero añadiendo en la retrospectiva de cada célula la colaboración (y en cierta medida supervisión) de los coaches.

• El fomento de la innovación general en la empresa sería otra interdependencia de alineamiento con la propiedad. Para ello usaríamos los mismos artefactos y ceremonias que en la descrita antes de fomento de la innovación en producto, pero con una ceremonia adicional, un concurso de innovación, sobre las mejores propuestas e incrementos de innovación. En su implantación, si hablamos de una gran corporación, podríamos definir distintas modalidades y ligas.

• Obtención de ventaja competitiva, usando como artefactos los elementos de mejora propia de los paved roads en los backlogs de las células y en los backlogs de producto, y las ceremonias de retrospectiva de las células de producto. Para alinear estas mejoras con la propiedad y con una estrategia de obtener ventaja competitiva, deberemos incluir en estas ceremonias a los angels. Del mismo modo necesitaremos que los maestros participen en ciclos de ideación de los paved roads.

• Para asegurar el cumplimiento de los umbrales de riesgo, algo fundamental y crítico en las corporaciones, podremos usar los cuadros de mando de umbrales de riesgo mencionados antes como ejemplo de artefacto, usando las retrospectivas de las células de producto (quizás de forma selectiva, no para todas) e incluyendo la colaboración (y en cierta medida supervisión) de los angels. Del mismo modo, sería deseable la participación de los maestros en ceremonias de sesiones formativas sobre gestión de umbrales de riesgo.

Finalmente, visitemos algunos ejemplos de interdependencias que podemos asociar a las funciones de gobierno, donde participan células de Angels y Coaches:

• Una podría ser la que busca la mejora de la agilidad a nivel corporativo, usando un backlog de mejora continua de la agilidad en la empresa como artefacto principal, y el comité de gobierno de la agilidad como ceremonia.

• Otra podría ser la que busca el incremento de la aportación relativa de valor, es decir, el aseguramiento de maximización del valor aportado por el conjunto de la empresa. Para ello se usaría el artefacto de valoración de incrementos (consolidado para el área de la empresa a valorar) haciendo uso de indicadores mercado y satisfacción.

• También sería importante la gestión del riesgo de negocio consolidado, haciendo uso de los Cuadros de mandos de umbrales de riesgo, pero de forma consolidada.

8.7 Coexistencia con la Empresa Jerárquica

Ya vimos que las células Agile podrían coexistir con la empresa jerárquica mediante relaciones con product owners y formando a líderes agile, del estilo de los que Jurgen Appelo propone en Management 3.0. Del mismo modo, podrían coexistir formaciones de células aplicando los mecanismos de escalado tipo LeSS o SAFe, siempre que éstos queden al amparo de líderes Agile.

En este capítulo de escalado vamos ya a imaginar una serie de células conectadas, trabajando de forma alineada, formando un ecosistema agile, un AEZ, que inicialmente será básico y lo entenderemos como ecosistema agile zero. Es imprescindible que en este ecosistema estén representadas las funciones del agile board y que entre las interdependencias de partida estén las relativas al gobierno de la agilidad, que veremos próximamente.

Pues bien, para el análisis de cómo integrar el sistema como un todo dentro de la empresa jerárquica, podemos obviar todas las interdependencias que son internas a la AEZ, entendiendo que han sido definidas según el criterio de las clasificadas en el primer grupo analizado más arriba (gestionadas e internas a la AEZ). Nuestro foco debe estar en las que unen células del ecosistema con el exterior. En este caso, deberán documentarse expresando su función y especificando las ceremonias y los artefactos usados, aunque éstas no sean favorables a la agilidad del ecosistema. Es decir, vamos a tratar las interdependencias gestionadas pertenecientes al gobierno ya establecido, las clasificadas como segundo grupo, e intentaremos convertirlas en las del tercero, como si fuesen interdependencias con el exterior, tomando como referencia para la frontera los límites del ecosistema.

Nuestro punto de arranque puede ser demoledor en cuanto a la falta de agilidad del sistema de partida, en el que las dependencias de las células del AEZ con el exterior sean rígidas y poco definidas. Para convertirlas en dependencias con el exterior, pero gestionadas y minimizando su impacto en la agilidad, necesitaremos la ayuda y el soporte de la dirección. En muchos casos, los departamentos o áreas de la empresa jerárquica dueños o promotores de esas dependencias querrán aferrarse a maximizar el alineamiento con independencia del grado de agilidad que permitan.

9 Sobre la Organización

9.1 Del escalado a la organización

Hemos visto en las dos capas anteriores cómo son las células, parte atómica del modelo, y como éstas interaccionan con su entorno para formar estructuras más complejas y para integrarse en el resto de la empresa jerárquica. Ahora, de cara a hacer el sistema más gobernable, es necesario identificar las áreas en las que se organiza un AEZ.

Si pensamos en una empresa jerárquica, el escalado se construye desde los individuos, agrupándolos en equipos dirigidos por un líder, que a su vez pertenece a un departamento junto con otros equipos, cada uno de ellos liderado por alguien con una categoría similar al del primer equipo, y todos ellos a su vez reportando al jefe del departamento. Este jefe puede pertenecer a un área, compartiendo comité de seguimiento del área con los jefes del resto de departamentos del área. Y así sucesivamente hasta llegar al CEO con su comité de dirección. La organización podría describirse por la misma estructura jerárquica, indicando el campo de responsabilidad de cada individuo del árbol jerárquico.

En realidad, podríamos también tener una estructura matricial, que no es sino una estructura doblemente jerárquica, añadiendo algo de complejidad. Los individuos seguirían, en general, teniendo claro quién es su jefe, quién cuida de ellos, pero tendría influencias en el trabajo de otros individuos pertenecientes a estructuras jerárquicas diferentes. Nos encontramos así con el CISO (Chief Information Security Officer) de una unidad pequeña reportando a su jefe local, pero a su vez siguiendo las directrices del CISO global. También en este caso la descripción de la organización sigue siendo bastante directa, donde el CISO local tiene su responsabilidad sobre la seguridad en la unidad, actuando según los criterios de su jefe, pero atendiendo a las directrices del CISO global, cuya responsabilidad es transversal en la corporación. En cualquier caso, el escalado y la organización van muy de la mano. Describiendo una, se describe la otra.

Eso no pasa exactamente así en la Agile Corporation. Y no pasa porque el objetivo que se quiere fomentar es precisamente el de la agilidad, eliminando la rigidez de las estructuras jerárquicas. Con anterioridad hemos expuesto como analogía la diferencia entre una dictadura y una democracia, siendo más sencilla la estructura en la primera que en la segunda. Es obvio que el juego de influencia y poder en esta segunda es también menos expeditivo, pero por otra parte garantiza una mayor capacidad de adaptación al cambio, derivando en un mejor sistema complejo adaptativo, que demuestra mayor longevidad.

En ACF pasa algo parecido. Las células tienen sus propósitos y se generan relaciones entre ellas para alinearse y con objeto de que emerja una capacidad extra del conjunto. Pero como no hay jerarquías, no podemos tirar de un nodo para recoger todas las células que dependen de él. En realidad, si lo hiciésemos posiblemente acabaríamos arrastrando todo el ecosistema, porque sería difícil que un grupo de células quedaran aisladas del resto. Por ello, en ACF necesitamos etiquetar la célula a nivel organizativo, o clasificarla, para así poder analizar el conjunto y gestionar su gobierno. Lo vamos a hacer partiendo de tres grandes grupos o áreas, para luego ir añadiendo gradualmente más especificaciones.

9.2 Las tres grandes áreas

La primera división organizativa de las células puede realizarse según la naturaleza de su propósito. Así llegamos a las tres áreas principales:

• Agile Board, cuyas células garantizan el valor para la propiedad o el accionista.

• Áreas de Expertise, agrupando aquellas células cuyo propósito es facilitar la generación de valor del resto de áreas.

• Área de Productos, con células orientadas a generar valor para el cliente.

La división comentada aplica a todas las capas del sistema, no obstante, no debemos visualizar estas áreas como silos o divisiones bien definidas. Si bien cada célula pertenecerá en esencia a una de estas áreas, admitiendo siempre excepciones a la regla, las relaciones entre ellas cruzarán todas las fronteras. Es decir, su clasificación o pertenencia a un área no dependerá de sus relaciones, sino de su propósito, tal y como se ha descrito poco más arriba.

Esta organización nos sirve para explicar el funcionamiento y por ello vamos a dedicar capítulos específicos a cada área en la última parte del libro, pero para poder entender cómo funciona el gobierno de la totalidad, debemos recorrer brevemente las tres áreas y sus características principales.

El área de productos recogerá, por tanto, todos los equipos de productos. Si miramos dentro de dicha área nos encontraremos posiblemente con subáreas muy diferenciadas dedicadas a productos muy concretos. Si los productos tienen poca relación entre sí, tampoco existirán relaciones entre los equipos de unos y otros. La cuestión es que la organización de esta área debe estar muy orientada a producto, siendo este hecho clave para el buen funcionamiento del sistema. Dentro de un producto podremos encontrar varios equipos separados, aunque coordinados y alineados. Aquí sí que hablamos de una especie de “ramillete” donde el nodo inicial es la célula de primer nivel, donde la ideación de más nivel ocurre y desde la cual van colgando otras células relacionadas entre ellas mediante interdependencias.

En cuanto al área de expertise, que recogería los clásicos servicios internos, aunque ya veremos que estructurados de forma diferente, la estructura interna es parecida a la de productos, excepto que aquí hablaremos de servicios o de componentes, todo ello orientado a aportar valor a los equipos internos. Si tenemos varios servicios bien diferenciados dentro de esta área, tampoco existirán relaciones entre células o equipos pertenecientes a distintas áreas. Pero si miramos el interior de una de ellas, encontraremos también una célula de primer nivel, donde reside la ideación de más alto nivel, desde donde cuelgan el resto de células mediante interdependencias.

Ya veremos en detalle que en cualquiera de las tres áreas podemos tener varios niveles. En las células de primer nivel reside siempre la ideación de mayor nivel, el “qué”, colgando de ellas las de segundo nivel que, a su vez, pueden tener carga de ideación que sea resuelta por células de tercer nivel, y así sucesivamente. En realidad, tal como hemos comentado ya, la distribución de carga de ideación o desarrollo existe en toda célula y termina siendo relativa dependiendo desde dónde se analiza. Un product owner puede considerarse a sí mismo 100% ideación, considerando 100% desarrollo a la célula que alimenta con su backlog, pero alguien de la célula en cuestión puede ser a su vez product owner del trabajo de una tercera, teniendo este individuo la misma impresión de hacer 100% trabajo de ideación.

Por tanto, tanto un área como la otra están compuestas por distintos ramilletes de células, un ramillete para cada producto o servicio. Dentro del ramillete hay cierta “jerarquía” de ideación de células, entendida sólo como mecanismo de alineamiento para centrarnos en el cliente (externo o interno) y dirigir todo el ramillete hacia la máxima aportación de valor. Dentro del ramillete nos podemos encontrar relaciones más complejas.

Cabe destacar que estas células de primer nivel que lideran los ramilletes no tienen ninguna célula por encima que les imponga algo sobre el “qué”. Sin embargo, tendrán la influencia de las células del Agile Board, que es la tercera área organizativa. Ésta está compuesta por una sola célula de primer nivel, a la cual estamos llamando la célula de oro, o golden cell. En realidad, si estuviésemos hablando de una empresa donde se aplicara el modelo de ACF al 100%, podríamos hacer una analogía de esta célula con el consejo de dirección, o board committee de las empresas tradicionales. Pero si hablamos sólo de un ecosistema AEZ dentro de la empresa jerárquica, esta célula de oro es tan sólo la que gobierna el ecosistema, asegurando su alineamiento con los intereses de la propiedad.

Si el ecosistema fuese muy pequeño, podría darse el caso de que esta célula fuera la única del Agile Board. En dicho caso estaría compuesta por una mezcla de agile coaches y de corporate angels. Si empezara a no ser suficiente una sola célula para gobernar todo el ecosistema, esta golden cell se dividiría en dos, quedando como célula de primer nivel la de corporate angels. A partir de ahí, se podrían producir particiones en nuevas células más complejas, todas ellas definidas intentando segregar las funciones de agile y coaches en células separadas.

Las células de angels deben mantener una estructura jerárquica entre ellas en lo que respecta a alineamiento. Además, podrán tener relaciones mucho más complejas entre sí y con el resto de las células del ecosistema, todas ellas relativas al alineamiento. Pero no se relacionan con todas, pudiendo delegar en las interdependencias de alineamiento entre células de distinto nivel. El objetivo fundamental del ACF es que la capa de gobierno sea delgada y ligera, pero efectiva.

Sin embargo, las células de agile coaches no tienen por qué tener una relación en forma de ramillete. Eso sí, en caso de carecer de célula de nivel superior, será obligatorio que tengan una relación con una célula de angels para garantizar así su alineamiento. Estas células, orientadas a garantizar el buen funcionamiento del sistema, pueden tener también una relación con el resto de células a las que inducir agilidad, tanto de las áreas de producto como de servicio. Incluso pueden tener relaciones con las células de angels para facilitarles a éstas su propia agilidad, independientemente de que reciban a su vez alineamiento de ellas.

9.3 Pero las cosas no son tan sencillas

En realidad, estas grandes divisiones tienen su sentido en grandes corporaciones, en grandes ecosistemas. Si hablamos de una empresa pequeña o de una startup no encontraremos dicha división. La función de coach no existirá o probablemente sea externalizada, la de angel será asumida de forma natural por la propiedad, que posiblemente también participe en el producto, y la de expertise, orientada a la generación de sinergia y control, difícilmente tendrá justificada su existencia. El resto del modelo de ACF es aplicable a cualquier tamaño de empresa, pero obviamente la capa de organización tiene su fundamento sólo para medianas y grandes empresas.

Pero yendo al otro extremo, si hablamos de grandes corporaciones podemos encontrarnos con otras complicaciones. Puede ser que tengamos varios ecosistemas diferenciados, cada uno de un agile board que lo gobierne, pero alguno de ellos pudiera ser que no tuviese área de expertise. Incluso lo contrario, podríamos tener un ecosistema dedicado sólo a servicios internos, es decir que tuviese sólo el agile board y el área de expertise careciendo del área que normalmente es la protagonista de todo el sistema, faltándole el área de producto.

Dicho esto, podría ocurrir que desde las áreas de expertise de un ecosistema se ofrecieran servicios a áreas de producto de otros ecosistemas, o que dos ecosistemas compartieran coaches.

Por tanto, podemos tener tanto ecosistemas incompletos o poco equilibrados, como relaciones que crucen distintos ecosistemas. Eso sí, en caso de que dos ecosistemas compartan el mismo agile board, y por tanto compartan la misma golden cell, serán considerados por el modelo como un único ecosistema, independientemente de que su estructura interna esté muy segregada o de que, geográficamente u organizativamente, sus equipos pertenezcan a distintas unidades de la corporación, o que posean una naturaleza muy desigual. Si se colocan debajo de la misma golden cell será por alguna razón. Si este hecho fuese más una desventaja que una ventaja, nada nos impediría partir el ecosistema en dos, con dos agile boards diferenciados, ambos integrados en la empresa jerárquica.

10 Sobre su Gobierno

10.1 Con Autoridad y Control, pero Sin Jerarquía

Ya hemos comentado que cualquier empresa tiene activos y, por tanto, tiene la necesidad de transmitir una autoridad desde la propiedad de dichos activos hasta los colaboradores menos afines, que garantice su gestión en favor de los intereses de la propiedad. Esto ocurre también en una agile corporation. Además, necesitará algún tipo de control que alerte de posibles riesgos que puedan amenazar dichos intereses.

Pero en el modelo de Agile Corporation esta transmisión de autoridad y el control deben ser compatibles con satisfacer las necesidades esenciales de Self Determination Theory. Y la clave para conseguirlo está en aprovechar en su plenitud las cualidades de un sistema complejo adaptativo. Bien es cierto que una empresa jerárquica sigue siendo un sistema complejo adaptativo, pero considera la agilidad de las partes (su libertad de autogestión) como una amenaza a la correcta gestión de los activos. Y como ya comentamos en el capítulo de Complexity Theory, si dicha empresa operara en un entorno simple y se enfrentara sólo a problemas simples, la Propiedad podría diseñar y planificar desde la cúpula de la empresa la estrategia perfecta que sus colaboradores deberían ejecutar, pero sería incapaz de hacerlo en el caso de entornos complejos, simplemente por una cuestión de inviabilidad de gestión del detalle.

A continuación, vamos a analizar dos diferencias fundamentales entre la empresa jerárquica y la empresa Agile en lo relativo a la gestión de la autoridad y al control sobre sus activos.

La primera diferencia con la empresa jerárquica es que en la empresa Agile dicha autoridad se limita a los activos de la empresa. El producto es un activo de la empresa, lo es su diseño, los procesos de su construcción, la infraestructura de fábrica, el stock fabricado y no vendido. No obstante, los equipos de trabajo que lo diseñan, lo desarrollan y lo operan, no son sus activos. Será importante tener en cuenta esta distinción para entender el funcionamiento de la agile corporation.

Mientras que la gestión de los activos se realiza en un área que llamaremos el Agile Board, el grueso del trabajo, como es la elaboración de la estrategia de producto, la realización de su diseño, la gestión de su desarrollo y de su operación, quedará fuera de la influencia directa de esa estructura que transmite autoridad desde la propiedad.

Esta parte de la gestión la realizan los equipos, los individuos de las células de trabajo, los líderes serviles y sus compañeros que les siguen. Esto es clave para liberar a las células de trabajo en su día a día de las rigideces de la estructura jerárquica, de su falta de agilidad, de las decisiones de micromanagement sin conocimiento de los detalles importantes, y así cumplir además con las necesidades esenciales de la SDT.

La segunda diferencia es que dicha autoridad no se proyecta como individuos con mando en plaza, sino como equipos de corporate angels que toman decisiones consensuadas.

En realidad, todo lo dicho sobre las necesidades esenciales de la motivación, la vinculación, la autonomía, la maestría y un propósito que compartir, es igualmente aplicable a los individuos encargados de gestionar los activos de la empresa, cuyo trabajo es 100% conceptual y creativo. ¿Por qué razón no íbamos a aplicar los mismos principios de SDT a los individuos que gobiernan?

Ya hemos comentado antes que, en realidad, todo individuo tiene en una organización cierto grado de gestión sobre lo que le rodea. Unos gestionan los activos de la empresa, otros la estrategia de producto, otros deciden sobre cómo se construye o sobre cómo se implementa, pero todo el mundo hace cierta labor de gestión.

Pero volviendo a la autoridad sobre los activos, Piensa Global, Actúa Local es una expresión que encaja muy bien con el espíritu de Agile Corporation. Se busca que con una visión global los equipos locales se adapten y sean ágiles para encontrar soluciones que resuelvan problemas específicos. Por ello decíamos que las interdependencias hacen viable que un conjunto de células funcione como una organización ágil, sin embargo, cada una de las interdependencias implica un grado menor de agilidad, aunque también un grado mayor de alineación.

El gobierno global debe poner foco en fomentar patrones clave para el negocio, tomar decisiones organizativas de muy alto nivel, asegurar que la agilidad tenga lugar en la organización y fomentar el liderazgo, tal y como veremos en el resto de este capítulo. Sin embargo, será importante interferir lo menos posible en el gobierno de las partes, en el gobierno de los equipos. El grado de libertad, entendido como la agilidad del sistema y conseguido con el número justo de interdependencias, es decisión de la Propiedad de la empresa y su amplitud dependerá de cada caso. Por un lado, podemos acabar con una organización con exceso de rigidez debido a un gran número de interdependencias definidas, que será torpe, pero por otro con una organización con exceso de libertad que será un caos. Tenemos que ir abandonando la aproximación del pasado centrada en el control centralizado, la coordinación absoluta y la planificación total, pero no proponemos hacerlo en un gran salto al vacío anárquico, sino con los mecanismos expuestos en las cuatro perspectivas de gobierno de este capítulo, lo cual esperamos que resuelva las dudas sobre la viabilidad de la alternativa.

Piensa Global, deja que las células de primer nivel determinen la estrategia general, tanto las que pertenecen a los productos como a las áreas de expertise o al agile board. Pero deja Actuar Local, permitiendo luego un juego de libertad y alineamiento para que las partes, más cercanas y sabidas de los problemas concretos, busquen soluciones que permitan adaptar a la organización aprovechando las oportunidades y esquivando las amenazas.

10.2 Perspectivas del Gobierno en una Agile Corporation

Al tratar la empresa como un sistema complejo, pronto saltó a nuestra atención que deberíamos poner foco en la gestión de patrones. Pero al mismo tiempo identificamos como clave el surgimiento de los líderes serviles, sin los cuales no hay movimiento, no hay adaptación. Una empresa donde sólo existieran patrones nos parecería una organización sin alma. Tendríamos células zombis, todas perfectamente alineadas, todas obedientes, de espaldas a la percepción del cambio en el entorno.

La agilidad también era algo que teníamos claro que debería ser gestionado y gobernado. ¿A qué grado de agilidad nos atrevemos a llegar? La respuesta fácil es que al máximo, siempre y cuando no rompamos el alineamiento con los intereses de la propiedad.

De esta forma hemos llegado a las cuatro perspectivas que a nuestro criterio deben ser tenidas en cuenta en el gobierno de una corporación con alta dosis de business agility, o agilismo. Estas son:

Patrones. Comportamientos generalizados y emergentes en el ecosistema o área organizativa, los cuales serán moldeados en lo posible por mecánicas de motivación extrínseca, aunque también serán impactados por los tipos de interdependencias que usemos de forma generalizada. Algunos propósitos buscados con la gestión de patrones son el alineamiento de toda la organización o área al compartir la visión corporativa, o bien fomentar la innovación, o conseguir el compromiso con la mejora continua de la agilidad, perseguir la generación de ventajas competitivas, adecuar la organización al apetito de riesgo adecuado, conseguir eficiencias mediante sinergias, etc.

Liderazgo. Desarrollo del yo en el ecosistema fomentando, como si fuese un patrón en sí mismo, el afloramiento de líderes serviles en las células, liderazgo que será relativo a una necesidad concreta y que podrá convivir con otros líderes serviles que empujen en necesidades diversas. Se buscará por lo tanto el compromiso individual con el conjunto, el liderazgo en maestrías dentro de las células, la definición o determinación de los propósitos concretos en cada célula, las actitudes de competencia y cooperación entre células, etc.

Alineamiento. Relación entre células que mitiga el riesgo de divergencia de los propósitos de las células con los intereses de la Propiedad, para lo cual usaremos interdependencias definidas a tal propósito. Algunas acciones fruto de dicho alineamiento podrían ser la determinación de crear, continuar o abandonar un producto, o la creación de una función transversal como Ventas, el incrementar o reducir la dotación financiera a un producto, etc. Para ello será necesario trasparentar lo importante con elementos de comunicación, tanto los propósitos como los avances, establecer ceremonias de supervisión y comunicación de feedback, y establecer mecánicas que aseguren la coordinación de las partes.

Agilidad. Preservación de los valores del manifiesto Agile en la forma de trabajar de las células, promoviendo la mejora continua en busca de más efectividad, completar las capacidades requeridas en el equipo, o acceso a ellas en el exterior, y adaptación continua del equipo al nuevo entorno. Esto implicará el seguimiento de las formas de trabajo agile, o la implantación de marcos de trabajo agile, asegurar el buen uso de artefactos, así como el cumplimiento de ceremonias, dotar a las células de las maestrías necesarias para su propósito, usar las técnicas y mecánicas de agilidad adecuadas, etc.

Como se apuntó en el Capítulo 2, si analizamos en detalle estas cuatro perspectivas veremos que están emparejadas dos a dos, generando cada par de ellas un yin-yang donde las dos perspectivas contrapuestas necesitan coexistir y desarrollarse para el buen funcionamiento de la organización:

• El Yin-Yang de la “Gestión del Propósito”, referido a la búsqueda de convergencia entre Alineamiento y Agilidad, sabiendo de antemano que ninguno de ellos puede llegar a ser el 100%, y que son opuestos. Dos herramientas importantes para este alineamiento, que no perjudican la agilidad, son los Paved Roads y el Risk Treshold Management, que veremos en detalle más adelante.

• El Yin-Yang de la “Gestión del Comportamiento”, dirigida a fomentar una cultura y unos valores positivos a nivel corporativo, a través de los Patrones, pero también el desarrollo del yo de cada individuo, promoviendo el Liderazgo Servil.

Este baile entre las perspectivas nos recuerda que no hay un modelo válido para dos situaciones diferentes. Si comparamos dos sistemas, dos organizaciones, la primera diferencia entre ellos podrá estar en su composición, ya sea en las capacidades de las células, en sus funciones, o en sus mecanismos de trabajo. Sin embargo, dos sistemas pueden ser similares en la naturaleza de sus células y resultar muy distintos, quizás porque las interdependencias que hacen actuar a las células se aplican de forma distinta, pero sobre todo por el modelo de gobierno que se aplique, que hará que ambos sistemas no se parezcan en nada, incluso que mientras uno sea viable el otro no sobreviva al cambio.

10.3 Los Patrones

Es fácil distinguir patrones en la naturaleza. Lo hacemos mirando la piel de un guepardo o cualquier otro animal, la geometría de las ciudades, las ondulaciones de las dunas, el comportamiento de las hormigas, etc. En la naturaleza surgen patrones de forma autoorganizada, sin que nadie, ni nada específico los fuerce. Emergen como resultado de las condiciones que afectan al comportamiento de sus partes, independientemente de que estas gocen de mayor o menor autonomía.

Para descubrir el potencial de los patrones basta con estudiar los modelos matemáticos básicos que se construyen con la finalidad de ver cómo simples reglas generan figuras complejas, por ejemplo:

https://naukas.com/2017/07/05/patrones-emergentes-hagalo-usted-mismo/

Los patrones son características de los sistemas que, en ocasiones, no pueden ser previstas con el análisis de las partes del sistema independientemente. Por ejemplo, estudiando el oxígeno y el hidrógeno por separado será difícil predecir las propiedades del agua como fluido. Podemos encontrar las mismas dificultades de predicción cuando estudiamos los patrones en las organizaciones. No las podremos identificar analizando individuos concretos, sino con una perspectiva global.

En los sistemas complejos adaptativos, los patrones surgen por la adaptación al entorno, por competición y cooperación, según las especificaciones que rigen el sistema y la naturaleza propia de los agentes que lo componen. Por ejemplo, si instalamos un torno en la entrada de la empresa y hacemos público el listado de suma de horas a la semana que los trabajadores pasan dentro de la empresa, es posible que surja un patrón de comportamiento entre los empleados en el que aumente el número de horas que permanecen en las instalaciones. Eso puede ser un patrón deseable cuando el trabajo es mecánico y además tenemos medios para asegurar que el empleado pasa todo el tiempo realizando la labor manual que tiene encomendada, pero aplicado a otro tipo de trabajo puede generar patrones indeseados donde la aportación de valor al cliente pase a un segundo plano.

Muchos patrones del comportamiento de los individuos en una organización forman parte de la cultura de la empresa. Un antiguo profesor decía que para conocer la cultura de un lugar había que preguntar cómo se sobrevive allí. Por ejemplo, si como respuesta a dicha pregunta escuchásemos estos consejos mostrados a continuación, denotaría la existencia de patrones de falta de agilidad:

• “No discutas con un director, aquí tienen mucho poder”

• “Que te vean en la oficina”

• “Aquí, quien a buen árbol se arrima, buena sobra le cobija”

• “Mejor nos reunimos abajo para que no nos vean”

• “Aquí, todo por escrito, que si no termina siendo culpa tuya”

• “Yo te lo hago, pero primero metes la petición en el sistema”

• “Pide 5 de más, que luego te exigen siempre gastar menos”

• “Para qué molestarse en pedirlo si te van a decir que no”

• “Los planes son para cumplirlos”

La gestión de los patrones es importante porque fomenta el alineamiento sin apenas mermar la agilidad, obviamente, siempre que los propios patrones no vayan en contra de la agilidad. Para gestionarlos es preciso efectuar un levantamiento de situación y estudiar los patrones existentes, los cuales pueden no ser obvios para la Dirección. Por ejemplo, uno de ellos podría ser el no escalar las malas noticias. Determinar los patrones más extendidos y con mayor impacto es algo crítico en el proceso de transformación. Si hablamos de una gran corporación puede ser que tengamos diferentes patrones en diferentes áreas.

Una vez identificados todos los patrones, deberemos establecer las interdependencias y mecánicas que corrijan aquellos que no deseemos y que fomenten los positivos. La determinación de los patrones globales o aplicables a un área concreta recae en el área del sistema que hemos denominado Agile board, no obstante, si aplicaran sólo a un producto deberían ser gestionados por los propios equipos de producto. En cualquier caso, el Agile Board establecerá los umbrales de riesgo aceptables para aquellas variables que se determinen como críticas. De igual manera deberán proyectar la visión global sobre los comportamientos que deseen fomentar y facilitar las mecánicas que favorezcan dichos comportamientos. Tanto las áreas de expertise como las áreas de producto, ambas centradas en aportar valor al cliente, deberán conocer los patrones fomentados a nivel global y facilitar su cumplimiento.

Disponemos de dos mecanismos para motivar el surgimiento de patrones. Podemos establecer un tipo de interdependencia que favorezca el patrón e implantarla o aplicarla de forma generalizada entre agentes o células. Por ejemplo, estableciendo un protocolo de fijación de objetivos trimestrales y su seguimiento por las células de corporate angels.

La otra forma de hacerlo es mediante mecánicas extrínsecas, con generadores de estímulos pseudo-predeterminados que de forma natural motiven comportamientos concretos. Por ejemplo, el torno en la entrada de las instalaciones, o el reconocimiento de maestrías con asignación de insignias como premio a aquellos que ofrezcan mejor soporte en un sistema interno colaborativo, el cual tendría como objeto el fomentar el patrón de la colaboración.

En ocasiones se confunde una cosa con la otra. ¿No es una interdependencia con el exterior una mecánica de motivación extrínseca para una célula? Veamos las diferencias que consideramos en el modelo para distinguir unas de las otras.

Las interdependencias se crean y se gestionan entre células concretas, lo cual no significa que no pueda haber múltiples interdependencias del mismo tipo en la organización afectando a diferentes células.

Por ejemplo, el seguimiento del backlog de producto.

Las mecánicas, sin embargo, se aplican a un conjunto de células pertenecientes a un área o al ámbito global de la organización. Producen unos estímulos que aplicados a la idiosincrasia de las células objeto moldean sus comportamientos.

Ejemplo: premios a la mejor innovación del trimestre

10.4 Mecánicas de Motivación Extrínseca

Para empezar, es obvio que si estas mecánicas se clasifican como de “motivación extrínseca” será porque precisamente están dirigidas a ese tipo de motivación. Recordemos que la motivación intrínseca es la de hacer las cosas por el gusto de hacerlas y que para eso tenemos la preservación de las necesidades esenciales de la teoría de la autodeterminación, lo que haremos mediante los elementos de gobierno que analizaremos en la perspectiva de agilidad. Ahora nos centraremos en la búsqueda de patrones mediante la activación de la motivación complementaria, la extrínseca, aquella producida por estímulos externos.

Las personas son en sí complejas y sus comportamientos son variables. El establecimiento de interdependencias con sus artefactos y sus ceremonias no garantiza el compromiso de los individuos con el establecimiento de propósitos alineados con la empresa, adquirir ellos mismos las maestrías que requieren para tal propósito, participar en el autogobierno de la célula para el bien del conjunto, o incluso establecer unas relaciones personales aceptables con el resto del equipo. Por otra parte, el sistema de premio o castigo aplicado a nivel global es insuficiente y a veces inapropiado cuando las mediciones realizadas son cualitativas y están delegadas a un ámbito muy local. Es necesario establecer por tanto unas mecánicas que, de forma natural, motiven el cumplimiento de las estrategias establecidas en las dimensiones de patrones, agilidad y liderazgo.

Las mecánicas son artificios que fomentan determinados comportamientos ante determinados estímulos. Así como las interdependencias establecen una relación entre células que facilitan o permiten una colaboración, las mecánicas estimularán a las células hacia dicha colaboración, y a su alineamiento en la dirección que interese a la empresa. Como mencionábamos en el capítulo relativo a Complexity Theory, un sistema evoluciona con base en estímulos, los cuales pueden ir desde el feedback del cliente ante una nueva versión entregada en el mercado, hasta el propio interés de un individuo por recibir una retribución más cuantiosa. Las mecánicas de motivación extrínseca son modelos que canalizan dichos estímulos con objeto de moldear los comportamientos. Hay que tener en cuenta que, si se dejase que el sistema evolucionara a su libre albedrío, sus células evolucionarían en su propio beneficio. Quizá tomarían decisiones sobre el producto que estarían muy alineadas con el cliente y con el espíritu de las células, pero nada alineadas con los intereses de la empresa, como veíamos en el apartado de Perspectivas de Gobierno.

Para aprovechar los estímulos en el caso del feedback del cliente, podríamos establecer mecánicas que sobreestimularan a los equipos para no caer en la autocomplacencia. En el segundo caso, para aprovechar la preocupación por la retribución que tiene cualquier individuo, crearíamos mecánicas para sacarle el máximo partido, o bien, para crear otros motivos de satisfacción que compensaran los motivos económicos. Otro ejemplo de aplicación sería incentivar y estimular el deseo de las células de desarrollo de cooperar con las células del servicio de arquitectura para establecer una sinergia en favor de todas, esto es, una situación en la que todas sumaran y produjeran un resultado mayor y mejor: 1+1>2. Tengamos siempre presente que las sinergias entre partes de la empresa son una de las verdaderas ventajas competitivas que le quedan a la corporación frente a la pequeña empresa o startup.

Al igual que ocurría con los artefactos y las ceremonias, para esto no hay un conjunto concreto de mecánicas a aplicar, por lo que a continuación veremos algunos ejemplos, según su tipo. Y hay que estar alerta, pues las mecánicas moldean comportamientos y, en ocasiones, lo hacen con efectos inesperados, por lo que su uso debe analizarse bien para evitar efectos indeseados. Por ejemplo, si se publicaran mensualmente el nombre y las cifras de ventas del mejor comercial a nivel mundial, esto podría deprimir a la gran masa de comerciales, que verían sus cifras ridículas comparadas con tamaño campeón.

Para ver en detalle las oportunidades que estas mecánicas nos ofrecen, podemos visitar los modelos o metodologías de gamificación, muy centrados en la gestión del comportamiento. En ellos podemos ver que se utilizan mecánicas de distinto tipo.

Las mecánicas competitivas, serían aquellas que fomentan la competición entre individuos y equipos, lo cual en sí es una palanca fundamental para hacer evolucionar sistemas complejos adaptativos. Tendríamos aquí iniciativas del tipo de publicar un ranking de productos por éxito comercial, o de dar puntos por aportaciones innovadoras.

Luego tendríamos las mecánicas de tipo reputacional. Aquí entrarían los sistemas de reconocimiento del individuo, como puede ser el resaltar sus maestrías, destacar su liderazgo o celebrar sus aportaciones pasadas o presentes. También pueden aplicarse a nivel equipo, motivando a éste a conseguir logros mediante la publicación y celebración de sus éxitos pasados y presentes, buscando estimular no sólo la aportación personal de cada individuo, sino el espíritu de equipo.

También queremos destacar las medidas de tipo social. Somos seres sociales y como tales queremos que nuestras relaciones se extiendan más allá de los límites de la célula, lo cual además es positivo para el sistema. Recordemos que, a mayor número de relaciones, mayor nivel de comunicación y mayor inteligencia en el sistema. Una forma de estimular esta comunicación es fomentar la participación del individuo en foros de opinión. También podemos fomentar la inteligencia del sistema incentivando la participación en laboratorios o permitiendo que los maestros den soporte transversal con sus maestrías, por el simple gusto de hacerlo.

Hay otro tipo fundamental de mecánicas de motivación extrínseca, y son las clásicas políticas retributivas. Podríamos implantar algunas según el éxito e importancia del producto, el aporte de valor de la célula, la aportación del individuo, la demostración de su maestría o de su liderazgo servil. Pero recordemos que Daniel Pink, en “la sorprendente ciencia de la motivación”, nos recuerda que este tipo de motivación puede ser contraproducente cuando hablamos de trabajo conceptual y creativo.

Hay dos ámbitos especiales para aplicación de mecánicas de motivación extrínseca:

El ámbito de la cooperación, bien entre individuos de la célula por la consecución de la aportación de valor, de los angels y coaches por el buen desempeño de las células a las que dan soporte, o entre las células de un mismo producto por el éxito del mismo como conjunto. Los ejemplos de comportamientos cooperativos que podemos encontrar son muchos.

Luego tenemos el ámbito de la competencia, donde buscaremos incentivarlas entre individuos por la obtención de premios, insignias y otros tipos de reconocimiento, o entre células por la obtención de reconocimiento por importancia de sus aportaciones de valor o propuestas de innovación, o entre equipos de producto por la hegemonía conseguida en el portfolio.

La existencia de esta dupla de cooperación y competencia entre agentes de un sistema complejo es fundamental para motivar su carácter evolutivo y adaptativo a los cambios del entorno.

10.5 El Alineamiento

Los problemas, los proyectos y las iniciativas en general que afronta una organización son complejos, tanto es así que no hay sistema de control, cuadro de mando, o proceso con la suficiente complejidad para gestionarlo de forma sistemática. Sólo las personas, los individuos, tienen la suficiente complejidad intrínseca como para hacer dicha labor. Las herramientas, los controles, y los indicadores son sólo sensores y emisores de información que las personas y los equipos deben interpretar para tomar y entender las decisiones, pero no se trata de conclusiones finales que generen órdenes o acciones predeterminadas (Jurgen Appelo, Management 3.0). 

Mientras que mediante la perspectiva anterior intentamos influir sobre la cultura de la empresa, el carácter de sus individuos, y sus comportamientos ante estímulos que vengan del exterior, en esta otra perspectiva trataremos los mecanismos de que disponemos en la Agile Corporation para controlar el alineamiento de las distintas partes que componen el sistema, cada una de las cuales resuelve problemas específicos y toma decisiones autónomas. Estos mecanismos son como las riendas de la empresa, que dirigen el rumbo sin interferir en la operativa interna del sistema, la cual está delegada en las partes que lo conforman, en esos individuos con la suficiente complejidad intrínseca y la suficiente información de detalle como para tomar la mejor decisión en cada caso.

Hay tres mecanismos importantes que debemos analizar, todos ellos como funciones del Agile Board:

• El primero es el de la dotación de fondos y organización de equipos, decididos por las células de corporate angels, que resultan determinantes al decidir en qué debe emplear la empresa sus recursos.

• El segundo es el alineamiento de propósitos, definido por los angels, pero supervisado tanto por ellos como por los Agile Coaches, un mecanismo sutil pero complejo, cuya correcta implantación es crítica para encontrar un resultado bien alineado, tanto con la aportación de valor al cliente, como con los intereses de la Propiedad.

• Y el tercero es la gestión de umbrales de riesgo, un mecanismo de control y gestión no intrusivo en la agilidad de los equipos, pero que mitiga los posibles daños colaterales al resto de la empresa.

10.6 Dotación de Fondos y Organización de Equipos

Cada producto, cada mercado, cada entorno requieren una organización, una estructura de información y unas capacidades distintas. El tamaño del equipo también influye en la organización idónea. A mayor tamaño, mayor distancia entre las operaciones y la propiedad, lo cual hace necesario establecer interdependencias a través de angels que aseguren el alineamiento de los propósitos. Finalmente, cada individuo, cada tipo de profesional, necesita una estructura particular para funcionar correctamente.

Por tanto, también el diseño de una organización es un problema complejo. No es una tarea como la de dibujar una estructura jerárquica al uso definida en modo top-down, sino decisiones concretas de creación/destrucción de equipos de productos/servicios, externos/ internos, que se autogestionan, así como equipos de corporate angels y agile coaches que aportan funciones propias de gobierno. También la estructuración de la organización debe ser un proceso de mejora continua, en el que los individuos quizá no tengan la sensación de tanto cambio al verse encuadrados en el mismo equipo, aunque se verán obligados como equipo a irse adaptando a las circunstancias del entorno donde se encuentre su célula, para lo cual será positivo que dispongan de máximo grado de agilidad.

Otro aspecto organizativo en el que el Agile Board puede influir, a través de sus angels y con el feedback de los coaches, es en la dotación del grado de autogestión que la célula vaya a tener. Dicha capacidad de autoorganización vendrá limitada por el entorno que los angels determinen a través de sus interdependencias. 

En un entorno de agilidad, las propias áreas de expertise y de producto gobernarán su propia organización interna, siempre y cuando estén alineadas con la visión global y se mantengan dentro de los umbrales de riesgo. En ese aspecto, aunque los equipos decidan en sus productos y proyectos, los angels y coaches determinarán el entorno.

Por último, una gran herramienta organizativa es la dotación de fondos, o incluso la substracción de fondos cuando se decida una estrategia de esquilmar el producto. Esta función se resuelve siempre en el ámbito de las células de angels, con decisiones delegadas a nivel local y entendiendo el detalle de cada caso, pero con asignaciones en cascada desde la célula oro. Ésta podrá delegar asignaciones parciales en otras células de angels con las que se relacione.

Mediante la dotación de fondos podremos aumentar o disminuir el peso de gobierno, mediante células de alineamiento (angels) y células de gestión de la agilidad (coaches), o las inversiones en productos, mediante la dotación de recursos a las células de primer nivel de dichos productos, o crear o disminuir servicios internos, mediante la dotación de recursos a las áreas de expertise. En cualquiera de los tres ámbitos mencionados, dado que la creación de equipos implica la asignación de fondos, esta función está en el ámbito del Agile Board.

Sin embargo, no deberíamos concebir dicha función como si construyéramos los equipos, seleccionando a los miembros, diseñando su funcionamiento, asignándoles un propósito, etc. Una de las necesidades esenciales de la SDT es la autonomía. Es cierto que dicha autonomía, que no independencia, puede ser de diferente grado, como equipos autoorganizados, autodesignados o autogobernados, implicando diferentes grados de agilidad.

En cualquier caso, sea del ámbito que sea el equipo, éste se autogestiona, con lo que deberíamos concebir esta gestión como si de hacer crecer a los equipos se tratara. El Agile Board lo crea, lo riega con financiación, le pone limitaciones o dirige mediante interdependencias, pero luego debe ser el propio equipo el que crezca y evolucione de la forma más oportuna y de acuerdo con su entorno y con los retos a los que se enfrenta. Una práctica muy aconsejable a la hora de construir equipos sería arrancar con tres recursos solamente y, en caso de necesitar crecer en número, hacer participar a éstos en la incorporación de los nuevos recursos.

10.7 Alineamiento de Propósitos

Los accionistas son los propietarios de los activos, propietarios de la empresa. Buscar valor para el accionista fue un objetivo muy común hace un tiempo y ahora es un propósito impopular. Pero sería ingenuo obviarlo ya que quien tiene la iniciativa de crear y hacer crecer una organización suele tener un propósito para hacerlo y, si el resultado no es el esperado, puede igualmente optar por desvincularse de la iniciativa. Sin embargo, no debemos confundir este propósito con el de la organización, sino que éste formará parte de la ecuación compleja que define al último. La estrategia de la empresa estará orientada a conseguir el propósito definido (la misión de la organización) y, de alguna forma, el resultado de cumplir esta misión debe favorecer los intereses de la propiedad haciendo cumplir su propio propósito.

Otro de los componentes de la ecuación para llegar al propósito de la organización es el propósito de aportar valor al cliente. Veremos que éste es el que hará viable el alineamiento de todos los propósitos particulares.

Finalmente tenemos el propósito intrínseco personal de cada individuo de la organización que, desde una posición inicial y sin haber recibido estímulos de alineamiento, nada tendrá que ver con el propósito de la organización. Por tanto, tenemos una situación en la que, desde una posición de partida, cada stakeholder tiene su propio propósito particular y éstos no tienen por qué estar alineados. En este sentido, el propósito propio de la organización, su misión, servirá de faro para alinear a todos los stakeholders.

Está claro, por tanto, que el propósito final y real de cada célula tiene una naturaleza compleja, que será específico para cada una de ellas y que además cambiará irremediablemente con el tiempo.

Para concretar, la fórmula del propósito de una célula estará compuesta primero por el propósito intrínseco de cada individuo pensando en sí mismo y el que emerge del equipo en su conjunto. También entrará en la fórmula el propósito extrínseco al individuo y la célula que se reciba de la organización para alinearla con el propósito global. Y finalmente tendremos en cuenta la motivación extrínseca que reciba cada individuo y el equipo en su conjunto como mecanismo para generar patrones globales. El resultado no tiene por qué ser perfectamente medible, pero debe ser claro, tangible y consensuado y, a ser posible, inspirador y un motivador intrínseco potente. Para ello, deberá ser cada célula la que formule su propia misión, para lo cual puede recibir la ayuda de los coaches y la supervisión de los angels.

Un ejemplo de propósito para un equipo de producto de una App de gestión de música podría ser “crear un mecanismo para el usuario de listas inteligentes, que facilite su consumo de música, perfectamente integrado en la App principal”.

Todo esto parece muy complejo, pero no lo es tanto. La cuestión es que no podemos obligar al individuo o a la célula a alinearse sin más con el propósito de la organización. Y aquí aparece el problema clásico: si generamos alineamiento controlando o forzando el propósito final de la célula con el de la organización, perderemos agilidad (este es el otro Yin-Yang que veíamos en el apartado de Perspectivas de Gobierno). Si damos libertad absoluta, lo más probable es que el equipo ignore totalmente el propósito de la organización.

El primer paso para lograrlo será definir el propósito de la organización, es decir, la misión. Esto está en el ámbito de la estrategia, por lo que los mecanismos clásicos de gestión de empresas son perfectamente válidos. La empresa tendrá una visión sobre el mundo en el que opera, y buscará su misión en ese mundo para aportar valor y llegar a dicha visión (y obviamente no nos referimos a la misión básica de hacer dinero). Será una función del agile board, de alguna de sus células de corporate angels, pero para la definición de la misión de una empresa hay ya mucho escrito. En nuestro caso, la misión ya definida como propósito de la organización es nuestro punto de partida.

El segundo paso es el traslado del propósito hasta la parte que corresponde a la célula. Esto también es pura estrategia convencional y también es función de las células de corporate angels. Tiene mucho que ver con la estructura organizativa vista anteriormente y con la forma de alinear las distintas áreas de la empresa para que sus porciones de propósito corporativo hagan exitoso el cumplimiento de la misión de la empresa. Pero no podemos decir en este caso que se haga de la forma tradicional, ya que lo que se suele hacer es descomponer la misión en submisiones, como si fuese un plan de abordaje. El problema de esta descomposición es doble: por una parte, si falla alguna parte esto afectará gravemente al resto, por otra parte, la descomposición planificada implica una rigidez ante cambios en el entorno. En el marco del ACF podemos tener descomposición del propósito general en subpropósitos, siendo algo inevitable en muchos casos, pero hay que fomentar el traslado del propósito, aunque añadiéndole especificaciones.

Por ejemplo, si nuestro propósito como agilecorporation.org fuese:

• “Aportar un marco de trabajo y servicios que ayude a las organizaciones y a los profesionales a diseñar e implantar el modelo Agile que convenga en cada caso”

¿Cuál sería el propósito para la célula que gestiona la academia?

Aplicando una estrategia de descomposición tradicional podríamos definirlo así:

• “Ofrecer formación sobre el modelo ACF”

asignando a la célula la función formativa.

Sin embargo, aplicando la fórmula del traslado también podría ser de esta otra forma:

• “Ofrecer formación sobre metodologías y mecanismos compatibles con el marco de trabajo ACF, ayudando a las organizaciones y a los profesionales a diseñar e implantar el modelo Agile que convenga en cada caso”.

En este caso dejamos a su criterio el elegir el tipo de formación que debe impartirse. Por ejemplo, impartirán más allá del modelo ACF unos cursos de Scrum si determinan que de esa forma se ayuda a la misión de agilecorporation.org de ayudar a implantar el modelo Agile que convenga en cada caso, aunque poniendo más énfasis en los grados de libertad que Scrum ofrece, en lugar de en las limitaciones que impone. Este tipo de traslado del propósito facilita que el propósito final resultante (al aplicar el intrínseco) se adapte siempre bien, independientemente de las particularidades que las células encuentran en su entorno.

Y esto nos lleva al tercer paso, aceptar el propósito de la célula. Este propósito ya viene dado y es diferente en cada caso, como se puede deducir de lo dicho anteriormente. Es la parte intrínseca de la fórmula de tres componentes y es importante para conocerlo y entenderlo, pues sólo así podremos abordar el cuarto paso. Las células de coaches ayudarán en esta función, así como en las siguientes.

Ya preparados, abordamos el cuarto paso, gestionar las relaciones (interdependencias) de cada célula con el entorno. De esta forma potenciaremos el propósito extrínseco derivado de la misión de la organización en la célula. Podemos hacerlo mediante un backlog de producto, un cuadro de mando, un indicador de riesgo, etc. Son las mecánicas de motivación específicas que alinean la célula con su función en la empresa.

Y esto nos lleva al quinto y último, añadir las mecánicas de motivación extrínseca oportunas. Aunque esto es una medida más general y está dentro de la perspectiva de patrones, también terminará formando parte del propósito final de cada célula. Por ejemplo, si detectamos en el tercer paso, a nivel global en un área, que en general hay un propósito de supervivencia, que refleja animadversión al riesgo, y nuestra misión como empresa requiere un esfuerzo extra en innovación, será imprescindible que implementemos mecánicas que fomenten el atrevimiento, buscando comportamientos más compatibles con la mecánica de prueba-error.

Finalmente diremos que las personas, de forma natural, tienden a internalizar los valores y las metas de aquellos con quienes desean sentirse conectados o vinculados. Una vinculación adecuada con la organización es en sí misma una motivación intrínseca que genera alineamiento de forma natural. El individuo adopta la cultura de los grupos con quienes se identifica, pero rechaza las normas o incentivos de las organizaciones con las que no tiene deseo de vincularse. Este detalle habrá que tenerlo muy en cuenta a la hora de decidir qué valores queremos tener en la empresa y cómo llevamos a la práctica su implantación.

10.8 Gestión de riesgos por umbrales

Y esto nos lleva a tratar el tercer mecanismo de alineamiento, la gestión por umbrales de riesgo (o Risk Threshold Management, RTM), que es clave para poder mantener el control sin interferir en el sistema.

Heisenberg enunció en su momento su célebre Principio de Incertidumbre, según el cual es imposible medir simultáneamente, y con precisión absoluta, el valor de la posición y la cantidad de movimiento de una partícula. En otras palabras: si se mide, se interfiere con el funcionamiento normal del sistema, o más exactamente, el sistema sin medidas es uno, y con medidas es otro diferente (o al menos aparenta serlo). Pues el mismo principio aplica a nuestro sistema de células, ya que las métricas modelan comportamientos y se verán alteradas con las medidas exhaustivas que impongamos. La solución es perder precisión, no menospreciar la medida cualitativa, delegar control y centrarnos sólo en aquellos posibles daños colaterales que un equipo pudiera causar al resto.

Esto es más fácil de ver con un ejemplo, como el aplicado al control de calidad de nuestros productos (o servicios). Si aplicamos controles de calidad “precisos” obtenemos dos efectos indeseados. En primer lugar, la aparición de trabajos y procesos derivados de las propias medidas de calidad, las cuales de por sí requieren un esfuerzo que no siempre está cerca de aportar valor al cliente. En segundo lugar, resultará de aplicar un control que la dinámica agile quedará entorpecida por el incumplimiento del segundo valor del manifiesto, esto es, la priorización de entregas de valor al cliente frente al cumplimiento de los protocolos internos (originalmente formulado como “SW funcionando frente a documentación detallada” y que nosotros hemos extrapolado a todo el negocio).

Para entender mejor este segundo efecto indeseado consideremos el ejemplo de los mecanismos globales de control de calidad. El resultado de la visualización de los detalles de calidad en informes que se escalan y consolidan a nivel de departamento o área alterará irremediablemente el orden de prioridades. El objetivo perseguido con este control es el de mejorar la calidad en la organización, objetivo muy loable y cuya existencia a priori puede parecer obvia y necesaria. Pero su visualización y escalado hará que el propósito de entregar la mayor aportación de valor al cliente con el mínimo esfuerzo se vea alterado por el cumplimiento riguroso de los procesos de calidad, anteponiendo este último al primero. Este efecto puede parecer menor al directivo de la empresa eficiente que, como norma, no concibe entregas de producto sin una calidad mínima, pero bastaría la experiencia personal de este directivo en el consumo de nuevos servicios proporcionados por empresas de éxito, para darse cuenta de que la calidad es sólo un atributo más del producto que se entrega, cuyo valor final es el resultado de la suma de todos sus atributos.

Sin embargo, si nos vamos al otro extremo donde no aplicamos ningún control de la calidad, ¿cómo estamos seguros de que un equipo, en una situación extrema de subsistencia, no decida poner en el mercado un producto con faltas de calidad evidentes que provoquen daños de imagen, de seguridad, e incluso financieros al conjunto de la compañía? Ahí es donde debemos aplicar la gestión por umbrales de riesgo o RTM, que aborda la situación analizando primero la respuesta a tres preguntas sencillas: qué riesgos en realidad necesitamos medir, cómo debemos hacerlo para no dañar la agilidad y cómo prevenir la materialización de dichos riesgos.

En cuanto a la primera pregunta, nos centraremos sólo en aquellos riesgos que realmente afecten al resto de productos. Aplicaremos el principio de “hazlo como quieras siempre que no afectes al resto”. Aplicado a la calidad del SW, sólo nos preocuparán desde un punto de vista global los defectos que lleguen a producción, obviando cualquier medida sobre eficiencia o calidad que ocurra dentro del proceso de desarrollo. Sabemos que esta falta de calidad en el proceso, aunque no llegue a producción, causa daño a las finanzas y la operativa del equipo de producto en sí, pero esto quedará dentro del ámbito de autogobierno del propio equipo, que verá como su propósito de producir software que funcione se verá perjudicado por la falta de productividad debido a la mala gestión de la calidad.

Para determinar cómo medirlos, aclarar que el propósito será hacerlo minimizando el efecto señalado por Heisenberg. Queremos hacerlo alterando al mínimo el sistema autogestionado de la célula. Aportaremos para ello servicios tipo carreteras asfaltadas, o Paved roads, de los que daremos detalles en el capítulo dedicado a las áreas de expertise, pero que ahora nos basta ver como servicios internos “ágiles”. La razón de crear estos servicios de medición es facilitar su captura interfiriendo en la menor medida posible en la dinámica agile del equipo y evitar añadirle la carga de la medición. Aplicado a la calidad del SW, por una parte, recogeremos los defectos que pasan a producción con el conocimiento del equipo, como resultado de haber tomado la decisión de poner el software en producción aún a sabiendas de que tiene defectos. Éstos estarán posiblemente en los backlogs, de las células de desarrollo, esperando a que llegue el momento de abordar su corrección, así que el servicio de captura lo hará directa y automáticamente a cambio de que el desarrollador los marque de alguna forma predefinida. Aparte, el servicio interno creado a tal propósito capturará directamente los defectos identificados en producción que no habían sido detectados por el equipo, lo cual es señal de falta de control dentro de la célula de desarrollo. De esta forma, el propio equipo tiene acceso a la información que la organización recoge, interfiriendo lo mínimo en su proceso y añadiendo solamente la necesidad de marcar los defectos que ellos identifican de una determinada manera.

Pero el objetivo final de alineamiento está en la tercera pregunta, cómo prevenirlos. Ahí, la solución también está en crear paved roads que faciliten el cumplimiento de los umbrales de riesgo establecidos. Lo harán proporcionando a través de estos servicios herramientas adecuadas, formación a maestros, o soporte a la gestión del equipo. Aplicado a nuestro ejemplo de la calidad del SW, pondremos a su disposición servicios de testing que requieran mucha especialización, tales como pruebas de portabilidad, de rendimiento, de cumplimiento de estándares de accesibilidad, de seguridad, etc.

10.9 La Agilidad

Podríamos decir que Agilidad es la autonomía que queda después de aplicar las normas de alineamiento, sin embargo, esta agilidad también debe gestionarse en diversos frentes:

• Definiendo las estrategias globales y facilitando su implantación

• Aplicando marcos metodológicos específicos de trabajo en las células

• Solventando las incompatibilidades con el alineamiento

• Gobernando la mejora continua a todos los niveles

Si bien los corporate angels participan en el primer frente, los verdaderos protagonistas de esta perspectiva son los agile coaches.

Estrategias Globales de Agilidad

Este frente es muy importante al comienzo, cuando se establece el AEZero dentro de la organización tradicional, pero decae en importancia cuando avanza la implantación del ACF por una razón bien sencilla: a menor estrategia global, más agilidad. Nos referimos a “estrategia de agilidad”, ya que la estrategia global ligada al cumplimiento de la misión tendrá siempre vigencia.

Cuando las grandes organizaciones desean implantar AGILE a menudo siguen este procedimiento:

1. Eligen un marco metodológico, por ejemplo, Scrum

2. Diseñan un modelo basado en dicho marco metodológico

3. Forman a los equipos en el modelo

4. Imponen dicho modelo corporativo

No obstante, ¿no es la autonomía de los equipos fundamental en Agile? ¿No debería cada equipo aplicar el marco metodológico que mejor se adapte a sus circunstancias?

Inicialmente puede no ser una mala estrategia imponer un modelo, por dos motivos. Para empezar, es mejor aplicar uno específico Agile seleccionado por la corporación, que seguir con los mismos modelos tradicionales. En segundo lugar, podría darse el caso de que el equipo no tuviera como referencia ningún modelo y ni siquiera estuviera formado en agile, con lo que pasaría a ser un equipo a la deriva. En cualquier caso, la forma de actuar debería ser que, a medida que cada equipo consiguiera tener las suficientes capacidades sobre marcos Agile, soltáramos cuerda y dejáramos que cada equipo se autoorganizara de la forma que determinara como más conveniente.

Sin embargo y para empezar, las estrategias globales no deberían ceñirse a determinar el modelo corporativo. En realidad, deberían centrarse en dónde aplicar primero las iniciativas de agilidad, en determinar qué áreas compondrían el AEZero y cómo se gobernaría el ecosistema. Como parte de la estrategia global también deberíamos determinar cómo formar a las células de agile coaches, así como sus interdependencias con los corporate angels, entre ellas mismas, y con los equipos de producto.

Aplicando Marcos Metodológicos Específicos

En este punto ahondaremos en la implantación de marcos metodológicos corporativos como una buena solución al principio, pero poco Agile en sí misma cuando los equipos tengan capacidad de autoorganizarse. Y es que todos necesitamos ser entrenados, aunque seamos muy buenos en nuestro campo. Por ejemplo, si Rafael Nadal pensara como la mayoría de los directivos piensan, dejaría de molestarse en tener un entrenador en el momento de llegar a ser número uno en su disciplina. Si es el mejor, ¿quién le va a enseñar algo nuevo? Para eso, recomendamos el mensaje que Atul Gawande, un famoso cirujano estadounidense e investigador de salud pública, presenta en un TED talk, donde nos abre los ojos a algo que es obvio: si quieres mejorar, consigue un entrenador. Él se pregunta cómo los profesionales mejoran en lo que hacen y presenta dos visiones. La primera es la tradicional, basada en que el profesional es capaz de gestionar su propia mejora estudiando e investigando por su cuenta, la cual de alguna manera se ve que funciona, ya que genera buenos científicos, buenos abogados. Luego tenemos la visión deportiva, la que considera que, independientemente de lo bueno que seas, no has llegado a la perfección, no has terminado de aprender. A Gawande, siendo un gran cirujano, se le ocurrió aplicar esta visión y contratar un entrenador que le hiciera mejorar su ya gran nivel de cirugía. El resultado fue que, de forma objetiva y basada en datos, él mejoró sustancialmente, aunque la persona que contrató como entrenador fuese un cirujano retirado que nunca había llegado al nivel que él ya mantenía. La visión objetiva y con una perspectiva distinta al individuo permite al entrenador ponerse en una posición de ventaja y poder proponer mejoras que de otra forma le pasarían desapercibidas. No hace falta decir que dicho entrenador debe tener las maestrías adecuadas para hacerlo. Debe conocer la materia y debe saber ser entrenador.

Pues esto mismo hay que aplicarlo a los equipos. Tanto si éstos acaban de empezar, como si ya son un equipo súper-productivo y afinado, deben seguir siendo entrenados por alguien que los vea desde fuera, como un observador inercial, y esa es precisamente la labor del agile coach. Entre sus distintas funciones estará la de sugerir marcos metodológicos alternativos al usado hasta el momento, o recomendar ajustes al marco existente para mejorar en ciertos aspectos.

Todo esto está hablado en lo que respecta a la célula, no obstante, quedaría ver qué ocurre con los productos complejos que requieren de numerosas células de trabajo, todas ellas sincronizadas y perfectamente alineadas para el propósito del conjunto. En el capítulo destinado a profundizar en el área de producto veremos que en el ACF no es necesaria la aplicación de modelos de escalado tipo Scrum-de-Scrums, SAFe, LeSS, si bien los acoge de igual manera en caso de que la organización decida implantarlos, siendo bienvenidos y compatibles. Nos aferramos a la teoría de la complejidad, según la cual no existe una solución válida para todos los casos, ni una solución que no encuentre un entorno en el que sea aplicable. Por tanto, los equipos de trabajo complejos, apoyados por los coaches, tendrán también a su disposición dichos modelos de escalado Agile como posibles soluciones, pero podrán adoptar evoluciones o mezclas de las mismas si se adaptan mejor a sus necesidades.

Solventando las Incompatibilidades con el Alineamiento

Ya hemos insistido algunas veces en que una empresa con una estructura muy jerárquica (mando y control) seguirá siendo un sistema complejo pero será poco ágil, y como sistema complejo adaptativo será torpe y poco viable si el entorno es cambiante. Además, tendrá muchas interdependencias entre sus miembros, aunque no estén documentadas, que normalmente tendrán una estructura en cascada desde el gestor de grado superior a los gestores de grado inferior, para garantizar el alineamiento. Estas interdependencias cubren todos los ámbitos de la gestión.

Sin embargo, estamos viendo que en la Agile Corporation gran parte de esa gestión se delega en las células de trabajo, donde nos encontraremos con gestores y con líderes ayudando a tomar decisiones en el equipo, dentro de su ámbito de acción. Esta estructura alternativa e interna de los equipos, en realidad limpia de interdependencias el ecosistema, haciéndolo más ágil y simple, ya que de esta forma sólo necesitaremos aquellas interdependencias externas a la célula, que aseguren su alineamiento haciendo cumplir los umbrales de riesgo y/o generando sinergias. Los coaches se preocuparán de que su funcionamiento sea efectivo. Para ello deberemos establecer unas estructuras específicas que revisaremos en el capítulo del Agile Board.

Gobernando la Mejora Continua a todos los Niveles

La mejora continua es clave en la filosofía Agile. Los marcos de trabajo Agile disponen de la ceremonia de retrospectiva, que busca establecer una mecánica constante de autocrítica por parte del equipo para así incorporar nuevas mejoras.

Si bajamos en nuestro análisis a la escala menor del sistema, cuando formamos un equipo Agile, al igual que si formamos cualquier otro tipo de equipo, pocas cosas funcionan bien. El equipo necesita tiempo para adaptar sus procedimientos en busca de eficiencia y eficacia en su trabajo. El coach deberá asegurarse de que también este proceso de mejora ocurre de forma eficiente en el equipo, asegurándose del buen funcionamiento de las ceremonias de retrospectiva y de que las mejoras identificadas pasan a formar parte de algún backlog del equipo.

Cuando escalamos en el sistema a conjuntos de células, como equipos de producto complejos o áreas de expertise, este proceso de mejora como sistema escapa a la gestión concreta de cualquier célula de trabajo. En estos casos son las células de coaches las que deben responsabilizarse de dicha mejora en la cual también deben participar los angels como supervisores del alineamiento con la misión de la empresa. Deberán existir, por tanto, ceremonias entre células de coaches y angels, así como artefactos específicos para componer interdependencias con este objeto.

10.10 El Liderazgo y los maestros

En un sistema basado en equipos autogestionados y multidisciplinares, que deciden su propósito de aportación de valor, es fácil ver que el liderazgo de sus miembros es crítico. Hay que tener en cuenta que, ya seamos CEOs, CFOs, Jefes de Proyecto o simples Consultores, todos somos gestores de lo que nos rodea. En realidad, todos tenemos un ámbito sobre el cual mandamos, sobre el cual adquirimos cierta responsabilidad o autoridad.

Un gestor pasa a ser un líder dentro de un grupo cuando encabeza e influye sobre un ámbito determinado. En la Agile Corporation, al igual que en cualquier otro marco Agile, estos líderes son serviles, porque dicho liderazgo no está acompañado de mando en plaza, sino que está basado en el servicio e influencia que dicho líder tiene en el grupo. Es por tanto un líder reconocido y respetado, y no un líder designado. Cualquiera, por tanto, puede ser un líder en este tipo de equipos. En realidad, veremos a continuación cómo podemos tener múltiples líderes en el equipo, cada uno liderando en un ámbito distinto.

Esto es el resultado del carácter multidisciplinar intrínseco de los equipos Agile, que viene dado por las maestrías que sus individuos portan y ofrecen al equipo. Está demostrado, y además así lo afirma Jurgen Appelo en su libro Management 3.0, que la diversidad es una característica favorable en los sistemas complejos adaptativos y que, de la misma forma, los equipos que muestren diversidad serán más efectivos. Obviamente la diversidad de sus maestrías deberá corresponderse con la diversidad necesaria para el propósito que se persiga.

Los líderes serviles surgen de los portadores de maestrías, de los maestros. Un miembro del equipo que esté formado en diseño para mejorar la experiencia de usuario (UX) terminará siendo reconocido en el equipo como el maestro en UX. Si este individuo posee ciertas dotes de liderazgo, será fácil que encabece e influya en las decisiones de UX que el equipo deba tomar. No significa esto que sea el responsable único en ese ámbito, pero si será el que presente la opinión más respetada y el que asuma las funciones relacionadas con dicha tarea.

Por tanto, un maestro es para nosotros un integrante de una célula que porta una maestría o una especialización.

Aunque los maestros son específicos para la diversidad requerida en cada célula, por lo que hemos visto en la perspectiva de alineamiento será muy normal que las maestrías estén relacionadas con los umbrales de riesgo a cumplir, o con los servicios tipo paved roads ofrecidos. Los maestros deben conocer bien la problemática, tanto ellos como otros que estén relacionados con sus maestrías, ya que deben ser líderes serviles en su célula para cumplir con los primeros y hacer uso de los segundos. La forma de fomentar o asegurar que esto ocurre es acercar a los maestros a las áreas de expertise encargadas de su implantación, asistiendo a ceremonias que motiven la afinidad del maestro con estos RTMs y paved roads, proporcionando además ideas y consejos para su evolución ya que, al fin y al cabo, los maestros son los clientes principales de estas áreas de expertise y, por tanto, estas deberán ser customer-centric escuchando cómo cambian sus necesidades o sus expectativas respecto del servicio ofrecido. Por tanto, el maestro participará como cliente en las ceremonias de desarrollo de las paved roads, en los ciclos de ideación de los servicios, y como proveedor o desarrollador en las ceremonias de seguimiento del cumplimiento de umbrales de riesgo.

Aunque tratamos el liderazgo como una perspectiva distinta a la de los patrones, el hecho de que surjan líderes de forma natural en los equipos es en sí un patrón deseado. Para que esto ocurra, antes debe surgir el patrón de empoderamiento de las células.

Pero primero analicemos la diferencia para nosotros entre líder servil y responsable como mecanismo de que las cosas terminen haciéndose de la mejor forma. En el momento en que alguien es responsable, sostiene la autoridad sobre una materia tratada por el equipo, y éste último perderá la capacidad de autogobierno sobre dicha materia. Es decir, en ese momento estaremos creando una limitación para el equipo, que eliminará la posibilidad de surgimiento de liderazgo dentro del mismo. En lugar de una acción de liderazgo, tendremos una de autoridad sobre esa materia. El resto de integrantes acatarán las decisiones, sin que el responsable tenga la necesidad de convencer ni liderar una propuesta. Tendremos entonces un líder, pero autoritario en lugar de servil, que respecto a esa materia estará fuera del equipo, que coartará las necesidades esenciales del SDT, en lugar de ser un líder servil desde dentro, que proponga pero acate la decisión de la mayoría, la cual normalmente terminará enriqueciendo la propuesta con sus objeciones y comentarios, para finalmente adoptar una opción que, si bien está alineada con la propuesta inicial del líder, está adaptada a las necesidades y la visión del equipo, que es lo deseable. La responsabilidad en nuestro esquema no desaparece, sino que reside en la célula, o en los equipos, en lugar de asignarse a individuos.

Si el empoderamiento es dar la responsabilidad sobre algo a alguien, pero además darle soporte en asunción de riesgo, crecimiento personal y cambio cultural (Quinn, Spreitzer, 1997), esto mismo es aplicable cuando hablemos de empoderar células. Algunos gestores temen al empoderamiento porque piensan que es un vaciado de su autoridad que los hace prescindibles. Pensar así es fruto de su miopía como gestores, pero es un hecho que evita la propagación del empoderamiento como patrón, por lo que deberemos implantar mecánicas de motivación extrínsecas que penalicen este posicionamiento a la vez que favorezcan el contrario, proporcionando al mismo tiempo a los gestores atribuciones y/o funciones que sacien su ego y calmen su ansiedad. Aun así, este es el gran escollo para la agilización de una empresa: buscar atribuciones y/o funciones al middle management para saciar su ego y calmar su ansiedad, y así permitirle ir entendiendo y aceptando la función de líder servil, finalmente más enriquecedora tanto para el equipo como para la persona.

Volviendo a las maestrías, justificantes del liderazgo, hacerlas públicas al sistema en su conjunto es una forma de favorecer su aparición. Certificarlas y publicitarlas es una forma de gamificar el sistema para favorecerlas. Hablamos en concreto de la implantación de una mecánica reputacional de motivación extrínseca que favorezca dos tipos de comportamientos: que los individuos del sistema persigan el reconocimiento público de ser maestros en algo que importe, lo cual les motivará a formarse y certificarse en dicha materia; y que el resto de los individuos hagan uso del servicio que el maestro está dispuesto a proveer.

La publicación de estas maestrías podría basarse en un artefacto tipo insignia, por ejemplo, “Certificado en UX”, de forma que pueda presentarse como el miembro del equipo con la coletilla “Master in UX”. Para ello deberá haber sido formado por las células de áreas de expertise correspondientes, o bien, que simplemente como reconocimiento de su maestría sea designado así.

Sin embargo, no debemos caer en el voluntarismo fácil pero estéril. No basta con desear tener líderes en los equipos para que finalmente los tengamos. Obviamente tendremos que establecer las mecánicas que hagan aflorar en nuestros colaboradores su espíritu innato de líder, el cual conllevará una motivación extra como resultado, sin embargo, si llevamos años y años contratando perfiles serviles y obedientes (que, eufemísticamente, habremos conseguido priorizando cualidades deseables como orientación al servicio y a los procesos, responsable, trabajador bajo estrés, dedicado, puntual, etc.), será complicado extraer mucho liderazgo de ellos. Será peor aún si hemos estado buscando líderes autoritarios o favoreciendo en la empresa a los narcisistas, dado que nuestra estructura jerárquica no transparenta la relación y el trato que éstos tienen con sus subordinados o compañeros.

Dado que siempre partiremos de ser una empresa eficiente, aunque no Agile, con responsables portando autoridad sobre grandes ámbitos, es crucial que el Agile board marque una estrategia que establezca unas mecánicas que minimicen en lo posible la contaminación del sistema AEZ con la cultura de que “el empleado debe siempre obedecer al superior”, así como reciclar a su gente para prepararla para trabajar en una Agile Corporation, donde la proactividad en el alineamiento y el liderazgo servil resultan cruciales para su funcionamiento.

10.11 Coexistencia con la Empresa Jerárquica

Es fundamental que la AEZ tenga su propio gobierno integrado y alineado con la corporación jerárquica. Esto ya estaba dicho cuando hablamos de la organización. Tanto esta integración como su alineamiento serán muy viables si la dirección de la corporación, la Propiedad, cree en la necesidad de agilizar la empresa y está decidida a intentarlo. Pero si esto no es así, la viabilidad de la iniciativa es mínima, o nula, y la recomendación es no afrontar la agilización en ningún caso. Sería una pérdida de tiempo y esfuerzo para llegar al aprendizaje supersticioso de “agile no es para nosotros, ya que lo hemos probado y no funcionó”.

En capítulos anteriores hemos visto como integramos en la empresa jerárquica a las células, a los equipos de células e incluso al ecosistema. Ahora vamos a ver cómo integrar el gobierno de dicho ecosistema.

Para empezar, deberemos revisar el funcionamiento de las células existentes y las relaciones que estas tienen con el exterior. La célula debe ser lo más autónoma y multidisciplinar posible, con libertad de elegir al menos el “cómo” abordar los objetivos especificados en los artefactos. Scrum es una buena aproximación si la célula pertenece a un equipo de desarrollo de producto. Por otra parte, Kanban puede ser un buen modelo para un área de servicio interno. En cualquier caso, el objetivo es tomar como referencia modelos que hayan demostrado la preservación de los valores y principios del manifiesto agile.

También necesitamos una célula que lidere la agilidad, un grupo de agile champions situados fuera del ecosistema pero alineados con la golden cell del AEZ. Ésta deberá analizar las cuatro perspectivas de gobierno que hemos expuesto (Patrones, Liderazgo, Agilidad y Alineamiento), identificando los objetivos clave en cada una de ellas, proponiendo alteraciones en las interdependencias de partida, y buscando el apoyo y empoderamiento de la dirección para el cambio.

Así, con la imagen de las interdependencias que cruzan los límites del AEZ y que merman su agilidad, pero que garantizan su alineamiento, y con los patrones conocidos de la empresa jerárquica que pueden ser perniciosos para el ecosistema, trabajarán los agile champions y la golden cell para establecer un roadmap de implantación de los RTMs, las paved roads y las mecánicas de motivación correspondientes, negociando con el resto de la empresa jerárquica la agilidad permitida al ecosistema.

Y es importante destacar que las medidas a tomar a nivel global, en la empresa jerárquica, para permitir esta agilidad, deberán ser diseñadas para motivar la aspiración de todos los individuos de la organización a pasar a formar parte de la AEZ, y no al contrario.

11 Sobre la Organización de Productos

11.1 Introducción al Área de Productos

Los equipos de producto tienen como principal componente de su propósito el generar valor para el cliente, pero deben hacerlo manteniendo el alineamiento con los intereses de la Propiedad. Están por tanto centrados en los productos finales, no en áreas funcionales o productos de consumo interno, que serán administrados por las áreas de expertise.

Son los “propietarios” de sus productos (cuando usamos el término “producto” nos referimos al ofrecimiento de la organización a sus clientes, ya sea productos físicos o servicios). Su libertad debería ser idealmente casi absoluta para definir el propósito en el que trabajan, decidir cómo se autogobiernan, o qué maestrías necesitan y cómo las van a conseguir. Sólo las interdependencias con las células del Agile Board, tanto las creadas con objeto de añadir al propósito final de estos equipos su alineamiento con la propiedad, como las diseñadas para promover patrones clave a nivel global, limitan dicha libertad. Debemos asumir que las relativas a las otras dos perspectivas de gobierno, aquellas establecidas para fomentar la agilidad y el liderazgo, quedan de por sí muy alineadas con su propósito principal de añadir valor al cliente.

Pero si el equipo de producto es grande y está compuesto por diversas células, el alineamiento entre ellas se realiza también mediante interdependencias como veremos a continuación. Pero este alineamiento de propósitos es más bien una coordinación de funciones para un fin común de todo el equipo.

Podemos resumir diciendo que las células de esta área organizativa son las que crean la estrategia de producto y las que luego desarrolla dicha estrategia. También podríamos incluir las que terminan operando todo lo relacionado con el producto una vez que está ofrecido al cliente. Todos los equipos con el propósito de añadir valor al cliente en lo relativo a un producto deberían formar parte de un equipo de producto global, desde su concepción a su soporte postventa, siempre y cuando la función no esté ofrecida como una paved-road sinérgica desde un área de expertise. El que se haga de una u otra forma es decisión del agile board. La suma de todos los equipos de producto hacen el total del área de productos.

¿Y cómo se gobiernan? O dicho de otro modo, ¿cómo se dejan gobernar?

Para empezar deben conocer los principales patrones corporativos. Para que eso ocurra, habrán recibido por parte de las células del agile board información de dichos patrones deseados en forma de valores, principios, normas, estándares o cualquier otra forma clásica de expresar los diferentes componentes de la cultura que queremos impulsar en la organización. El objetivo es que esta red de instintos artificiales resultante de la gestión por patrones llegue a los individuos de todas las células, ya sean del área de producto, del área de expertise y, por supuesto, del propio agile board. A parte de recibir información sobre la cultura deseada, ya está dicho que las mecánicas de motivación extrínseca desarrollarán estímulos que modelen los comportamientos de las células y sus individuos de acuerdo a estos patrones.

El liderazgo en sus filas debe surgir en varias direcciones. Por una parte tendremos los líderes que son maestros de aquellas capacidades que sean críticas para su propósito. Pero también surgirán los que promuevan los valores y principios culturales, o faciliten el trabajo en equipo. En general, podríamos decir que deberían surgir líderes para afrontar cualquier reto o necesidad que surja en el equipo.

A nivel alineamiento, ya que son propietarios de sus productos, también deberían decidir cómo organizarse. Es decir, deberían definir su estructura en células, pero también sus artefactos y las ceremonias que coordinan todo el desempeño. Pero al mismo tiempo deben alinearse con la organización conociendo los umbrales de riesgos que deben cumplir y los paved-roads que tienen a su disposición.

En cuanto a la agilidad, es algo que debe estar en los genes de los equipos. Para una empresa agile, necesitamos profesionales agile. Estos asumirán su responsabilidad, como equipo, de asegurar que las relaciones e interacciones entre sus individuos sean aprovechadas, de interiorizar una obsesión absoluta por la entrega de valor, de buscar siempre la colaboración con quien determina su propósito y de poseer una gran capacidad de adaptación al cambio. Al mismo tiempo tendrán también bien interiorizados los principios del manifiesto, gestionando su mejora continua no por voluntarismo, sino con mecanismos adecuados para ello.

11.2 Relación entre Producto y Células

La célula es algo concreto y muy determinado. Es un grupo de trabajo compuesto por individuos concretos. Entre todos determinan su propósito y se autogobiernan, compartiendo responsabilidad sobre lo que hacen, y lo que no hacen. El equipo de producto es algo más ambiguo. Lo forman cualquier individuo o equipo que participe en la ideación, el desarrollo, el despliegue o la operación de dicho producto, sea cual sea la célula a la que pertenezca. Entremos en un poco más de detalle para aclarar este punto.

Un producto sólo puede estar liderado por una única célula, entendiendo este liderazgo como el alineamiento de todas las células que trabajan en él. A esta célula le llamamos célula de nivel 1. Creemos obvio pensar que un producto deba estar liderado por una única célula, aunque luego colaboren muchas más a través de interdependencias que cuelgan de la célula de nivel 1. Pero esto es perfectamente compatible con que varias células puedan participar en los detalles de su ideación y en el desarrollo de los elementos del backlog de producto resultante. Cómo se organicen las células para abordar el trabajo es algo que dependerá de cada situación.

También se puede dar el caso de que una célula trabaje en dos productos distintos, situación especialmente probable en empresas medianas o pequeñas. En realidad, una vez cumplida la regla mencionada arriba, que un producto sea liderado por una única célula, las combinaciones pueden ser múltiples. Una célula puede ser de segundo nivel para el producto “A”, colaborando en su ideación, pero de primer nivel para el producto “B”, siendo la que lidera dicho producto. Estas situaciones deben ser analizadas en detalle a la hora de definir los artefactos y ceremonias que gobiernan sus relaciones En este caso, es posible que, existiendo diferentes backlog de producto, uno para cada producto, el equipo haya adoptado un modelo en el que, cuando se planifique su trabajo, todos los elementos de los backlogs de producto que se vayan a acometer, vayan al mismo backlog de equipo, ordenando ahí el trabajo para acometer ese sprint o coordinando prioridades para la ejecución de trabajos.

En cualquier caso, vemos que podemos tener células que trabajan en varios productos, así como productos trabajados por varias células, generando una estructura que, o bien etiquetamos y representamos adecuadamente para su gobierno, o será vista como un amasijo de células, artefactos y ceremonias cuyos mecanismos de coordinación serán difícil de predecir.

El caso es que hemos hablado hasta este momento alegremente de equipos agile y de células agile, como si ambas cosas fuesen equivalentes. En realidad, prácticamente todo lo que se dice para una es válido para la otra, pero desde el punto de vista de nuestro modelo, cuando usamos el término “equipo agile” no nos referimos específicamente a una célula, sino a la estructura de ellas que persiguen un propósito concreto, como el desarrollo de un producto, liderado por una célula de primer nivel. Es decir, un equipo es la célula de primer nivel y todas las células relacionadas a través de interdependencias cuya misión sea contribuir a ese propósito, quedando excluidas las de corporate angels con la misión de alineamiento o las de agile coaches que facilitan la agilidad.

Si analizamos un poco más profundamente estas estructuras de productos, podremos encontrarnos con los siguientes tipos:

• El producto en sí, con el cual interactúa directamente el cliente. Por ejemplo, la app de cualquier banco en iOS o Android, o parte de ella, como Bizum. Que se considere un producto a parte o no dependerá de lo independiente que sea su liderazgo respecto al primero. Es decir, Bizum podría ser un producto si se desarrolla con independencia, por una célula de primer nivel, ofrecido a través de la app principal, que sirve de canal y que a su vez es otro producto. Pero podría también abordarse como una funcionalidad concreta de la app, vista como producto único. Si

• Un subproducto, cuando hablamos del desarrollo de una parte del producto. Es el segundo caso descrito anteriormente con Bizum, o por ejemplo, “mostrar posición integral del cliente” en la misma app. Aunque puede existir una célula de primer nivel para ese subproducto, esta en realidad estará supeditada a las ideaciones de la célula de primer nivel del producto al que pertenece.

• Un componente, que es un subproducto utilizado en varios productos. Esto genera una sinergia, pero también una complejidad, ya que no hay una estructura de interdependencias “jerárquica” para el alineamiento del producto, donde una célula de ideación establezca elementos del backlog de la de desarrollo. En este caso, la célula de primer nivel del componente, deberá ver a las células de ideación de los productos que usan su componente como si fuesen clientes. Por tanto, también existirán interdependencias entre ellas, aunque funcionarán de forma diferente. Un ejemplo siguiendo con el caso de la app financiera podría ser la función de login-in, usada en todas las apps financieras del banco. Otro ejemplo serían las APIs internas para mostrar saldos de cuentas personales o realizar transferencias.

11.3 Construyendo el modelo desde el individuo

Presentamos el Agile Corporation Framework como un marco organizativo. Si el lector decide aplicarlo en su empresa, es necesario primero que adopte el rol de agile coach y segundo que lo represente y lo defina de forma visible. Sólo de esa forma podrá analizarlo en su globalidad y mejorarlo. Más aún, si el lector quiere aplicar este modelo lo normal es que desde el principio lo haga “en equipo”, con lo que necesitará compartir dicha información con los demás miembros del equipo. En ciertos momentos deberá asumir él mismo, u otro de los miembros, o todos en general, el rol de corporate angels para valorar si el modelo que estamos definiendo va a generar un ecosistema suficientemente alineado con los intereses de la propiedad. Para este propósito, invitamos a este lector a representar el modelo como mejor le parezca, pero vamos a sugerir una primera forma esquemática de ir documentando y representando el ecosistema agile que vamos construyendo.

Para empezar, necesitaremos tener una tabla con individuos y las materias que dominan, las maestrías. Obviamente especificaremos aquellas que son relevantes para el ecosistema, pero en caso de duda sobre la relevancia de una maestría que “viene” con el individuo, sugerimos siempre añadirla a la lista. Cómo documentemos y hagamos visible esta información tiene poca importancia y, como casi siempre, puede depender de cada caso. Si por ejemplo prevemos que las maestrías van a repetirse muy poco, quizás lo mejor es que la tabla tenga dos columnas, donde en cada fila indiquemos el nombre del individuo y la lista de maestrías que posee. Si el número de individuos es grande, mientras que el número de maestrías relevantes para nuestro ecosistema es finito y gestionable, podríamos optar por una matriz donde las filas son los individuos y las columnas son las maestrías. En cada celda indicaríamos el nivel de maestría. Se haga como se haga, lo importante es tener claras que maestrías son relevantes para nuestro ecosistema y qué individuos portan dichas maestrías, es decir, quién son los maestros en nuestra organización.

Es posible que los coaches, con afán de facilitar mejor la agilidad, quieran recabar mucha más información relativa a cada individuo. Esto puede ser de gran ayuda y animamos a hacerlo, lo cual nos llevará a crear una “ficha” por cada individuo. De esa forma, los coaches pueden identificar posibles incompatibilidades, potenciales faltas de liderazgo y muchas otras cosas que “arreglar”. Donde a nuestro parecer se equivocaría el coach es en sobregestionar la célula. Al igual que en futbol se dice en ocasiones que un entrenador peca de entrenar en exceso, coartando la iniciativa de sus jugadores, lo mismo deberemos vigilar en nuestra función de coach, dejando en lo posible que los individuos de la célula gestiones sus problemas y mantengan su iniciativa, que tanta importancia tiene en cualquier tipo de equipo, ofreciendo ayuda y nuestro análisis sólo cuando estos conflictos o mejoras no se consiguen resolver internamente.

Luego podemos pasar a las células, las cuales representaremos así:

Esta es la célula llamada “Los lobos”. Ya hemos visto que las células son un organismo atómico básico para el modelo, por lo que será importante darles nombre para poder referirnos a ella. Hay literatura sobre equipos agile que sugieren que la célula sea bautizada por el mismo equipo. Obviamente la “organización” de coaches podrán poner ciertas normas en la elección de nombre para que no queden malsonantes dentro del conjunto. Como curiosidad para el lector, los que hemos contribuido a la definición de este modelo y a escribir este libro que lo refleja somos la célula de “los Jets”. Puede haber o no razones para la elección de un nombre en particular y en nuestro caso la hay, pero no es de interés para lo que nos ocupa.

Pero con la importancia que tiene la célula para el modelo, deberemos documentar mucha más información sobre ella a parte del nombre. Lo ideal es generar otra “ficha”, una por célula, con toda la información que vamos a ir especificando en esta sección.

Para empezar, lo más importante: qué individuos la componen. Y cómo, aunque no muy recomendado, es posible que un individuo participe en varias células, quizás también debemos representar un porcentaje aproximado. Como nota, si hablamos de forma poco categórica es porque uno de los corolarios de la teoría de la complejidad es que no hay sistema único perfecto para todos los casos, y tampoco tiene por qué haber una única forma de representar/documentar el modelo que sea perfecta para todos los ecosistemas.

Otro detalle importante es sobre las maestrías de la célula. Por una parte, tenemos las maestrías que posee la célula, lo cual es deducido de las maestrías que portan los individuos que pertenecen a la célula. Sin embargo, no debemos olvidar la lista de maestrías “requeridas” en la célula según el criterio del agile coach. Cuando especifiquemos éstas en la ficha de la célula, podremos analizar el gap entre las requeridas y las aportadas por los miembros, lo cual pronto nos llevará a planes de mejora para la célula.

Una sección importante en la ficha será la declaración del “propósito” de la célula, el cual puede tener varios componentes. Si una célula trabaja en dos productos, lo normal es que el propósito de dicha célula tenga dos misiones, una para cada producto, aunque en el fondo sean sinérgicas y parecidas. Esta información es muy relevante para el análisis del alineamiento de células.

Dicho alineamiento quedará complementado con dos secciones más también importantes en la ficha de la célula. Hablamos de las carreteras asfaltadas, o paved-roads, que ya disponemos y que podrían aplicar a la célula, aunque no son obligadas, y los umbrales de riesgo que la célula debe cumplir y que limitan su autonomía.

Finalmente, vemos necesaria una última sección en la ficha: el kanban de mejora continua interna de la célula. Este kanban, y las medidas que en él se representan, es gestionado por el equipo, si bien alguna de las medidas requerirán ayuda de los coaches o incluso de los corporate angels. Para empezar, ese kanban debería ser visible para la célula y estar expuesto en alguna pared cercana o con alguna herramienta compartida. El coach podría tener en la ficha una foto sobre el estado de la tabla tomada de forma periódica, pero en realidad, o bien se interesa por la mejora de la célula y de alguna forma participa en alguna de las ceremonias que la usan, o de poco le servirá tener dicha foto en la ficha, ya que no sabrá el por qué de las cosas. Podría ser algo como lo expuesto a continuación, con cuatro etapas. La etapa de ideas, donde se colocarán mejoras a ser analizadas por el equipo, la de to-be, con aquellas que el equipo decida abordar, la de WiP (work in progress) con aquellas que el equipo está intentado abordar, y finalmente la del “done”, donde dejaremos por un tiempo aquellos logros conseguidos, con objeto de que sirvan de motivación y para alertar de no volver atrás dejando de hacer algo que probablemente nos ha costado implantar.

Para seguir aportando sugerencias de representación del modelo necesitamos ver cómo vamos escalando desde la célula al ecosistema.

11.4 Representación de la relación entre células

Hemos definido un esquema para dibujar las relaciones entre células y así poder representar los equipos como conjunto de ellas. Nuevamente, el lector puede establecer la suya propia, ya que esta representación no es inherente al modelo, sino sólo una propuesta.

Al igual que necesitamos documentar las células, necesitamos documentar las interdependencias que generan las relaciones entre ellas. Estas sabemos que están compuestas por al menos un artefacto y al menos una ceremonia. Por tanto, la ficha para tal interdependencia describirá los detalles de ambos componentes.

Para representar visualmente dicha relación, una interdependencia formada por un artefacto “A” y una ceremonia “C”, en caso en el que queramos expresar los detalles de dichos elementos, podría representarse así:

Si la interdependencia es interna y sobre la gestión del equipo podríamos obviar representarla, pero si por algún motivo hace falta, podríamos hacerlo así:

Pero si lo que queremos es representar la relación de influencia entre dos células, entendiendo que dicha relación tendrá siempre un artefacto y una ceremonia al menos, la representación propuesta es esta:

Hay que destacar que esta relación de influencia tiene un ámbito específico concreto, que puede ser el relativo a un producto. Es decir, una célula podría trabajar con varios productos, llegando influencias distintas desde células de ideación distintas dependiendo del producto. Esto lo vamos a ir aclarando más tarde.

Ahora imaginemos que queremos representar el funcionamiento de un equipo scrum. En dicho caso, la célula de ideación estará compuesta por un solo miembro, el Product Owner, propietario del backlog de producto en dicho marco metodológico. Al mismo tiempo existe un Scrum Master, una especie de agile coach en nuestro modelo, pero obviemos dicha relación y esperemos a representar su relación con el equipo hasta que lleguemos al agile-board. La primera representación simplificada de este equipo de trabajo sería esta:

Pero si queremos explicitar los elementos usados en la relación, deberíamos representar algunos de estos. En Scrum existen tres artefactos: el backlog de producto (P), el backlog de Sprint (S) y el incremento (I). Además, existirán 4 ceremonias: El daily (D), el Sprint planning (P), el Sprint Review (R1),y la retrospectiva (R2). Hay una tercera relación importante, la tarea de refinamiento (R3).

A nuestro parecer, todas podrían representarse con una única relación, ya que por una parte las dailys, las retrospectivas y el Sprint Backlog son de autogobierno de la célula, por otra, el incremento es el resultado del backlog de producto ya realizado, aunque siguen siendo dos artefactos diferentes. Por tanto, en una representación simplificada, lo dibujaríamos así:

Pero si quisiésemos ser muy ortodoxos con la representación, nos podría quedar algo como esto, en el cual hemos añadido un cuarto artefacto, el kanban (K) de mejora continua para el propio equipo:

Por tanto, podemos representar algo muy complicado, o muy simple, depende del propósito que tengamos al representarlo.

Destaquemos que las ceremonias y artefactos internos (D, S, K y R2) son específicos de la célula e independientes del producto. Sin embargo, las que son externas (P, R1, R3 e I) conforman la relación de influencia de un elemento exterior (en este caso un product owner) con la célula para un producto, o conjunto de productos, específicos. En ACF no descartamos que una célula de desarrollo trabaje con varias células de ideación. La limitación es que un producto tenga más de una célula de ideación de primer nivel.

11.5 Escalado desde las células a equipos de Producto

Si bien, como ya se ha dicho, el modelo que relaciona a los distintos equipos que componen el desarrollo de un producto puede diferir en cada situación, hagamos una abstracción y simplifiquemos el análisis. Pongamos foco sólo en las interdependencias dirigidas al alineamiento dentro del equipo de producto, es decir, a que todas las células que trabajan en un producto lo hagan de forma alineada con la célula de primer nivel de dicho producto. Al mismo tiempo, aunque sabemos que puede haber un enredo entre productos y células, hagamos este análisis tomando solo a vista sobre un único producto.

Así, si queremos ver como escala un producto desde su estado embrionario, al comienzo de todo el equipo estará compuesto por una única célula que hará todo, pero que obviamente al encontrarnos en la concepción del producto, casi todo lo que haga sea trabajo de “ideación”.

Cuando empieza a germinar, generando más carga de trabajo, llegará el momento de separarla en dos células, una con más carga de ideación y otra con más carga de desarrollo, que estarán unidas por una interdependencia. No vamos a profundizar en cómo se realiza este paso por su simplicidad y porque ha sido ya tratado anteriormente cuando veíamos la composición de la Agile Corporation.

Si sigue creciendo la carga de trabajo es posible que el equipo necesite una tercera célula. Si esta célula va a procesar trabajo “del mismo tipo” (algo muy subjetivo) que la de desarrollo existente, lo normal sería que compartieran los mismos artefactos. Esto es, compartirían un mismo backlog de producto, asignándose distintos elementos entre unos y otros. Si todo se hace en la misma ceremonia, hablaríamos de compartir la misma interdependencia (mismo artefacto y misma ceremonia). Si esto debe ser así o no, dependerá de lo viable a nivel logístico que resulte en cada situación. Si se usa un backlog común para las dos, los elementos pueden o no estar asignados a una célula en particular. Una opción podría ser que cada equipo va eligiendo los elementos que mejor le encajan dentro de la prioridad definida por la células de ideación. La siguiente gráfica muestra esta relación entre tres células, los lobos, los gatos y los perros, compartiendo el artefacto A1, pero con seguimiento en distintas ceremonias, C1 y C2:

Por conveniencia, ya sea logística o simplemente que las dos células de desarrollo se ocupan de trabajo de naturaleza muy distinta, podría darse el caso de tener que arrancar un segundo backlog.

Si sigue creciendo, quizás sea necesario una cuarta célula en el equipo, pero esta también es de ideación. Una forma de representarlo podría ser esta:

Nada especifica si es de ideación o desarrollo, pero eso es algo que como vimos resulta subjetivo y creemos que no debería especificarse en el diagrama por llevar a engaños. Desde el punto de vista de los lobos, célula de primer nivel, las otras tres son de desarrollo, aunque los gatos y perros estén dedicados a desarrollas una app (por ejemplo) y los tigres a idear un subproducto que será integrado en el producto principal. Sin embargo, si queda claro en la representación de la relación, como se puede ver, el sentido del alineamiento.

Una vez que la célula de ideación de segundo nivel, los tigres, generan trabajo suficiente como para alimentar a una nueva célula, podría aparecer un nuevo backlog para comunicarse con la nueva célula de desarrollo:

Hasta aquí, todo lo hemos hecho de forma simplificada imaginando que cada célula sólo trabaja en un producto (o subproducto). Pero compliquemos el asunto, porque en las grandes corporaciones las cosas son mucho más complicadas con sus grandes productos. Y eso da pie a un análisis previo sobre la simplificación como factor clave del éxito: ante una situación complicada, busquemos simplificaciones. Estamos ahora viendo como representar relaciones de grandes y complejos productos, pero el agile board debería trabajar siempre en simplificar las estructuras y los propósitos. Pero imaginemos que eso es imposible. Si los tigres trabajan en realidad en un subproducto que satisface a más de un producto, se convierte como vimos anteriormente en componente. Su célula de ideación pasa a ser de primer nivel y tendrá a las células de ideación de los otros productos como principales clientes. En dicho caso estaremos en una gráfica parecida a la expuesta a continuación, que como veremos no daremos como válida:

En este caso, las interdependencias verticales entre tigres y células de primer nivel serían algo distintas en naturaleza a las otras. No serían tan unidireccionales en alineamiento como las otras, ya que los backlogs de los lobos y los del segundo producto podrían ser en algunos casos incompatibles. En realidad, estas dos células de productos diferentes deben “negociar” de algún modo el backlog de entrada de los tigres. Y si los tigres no fuesen capaces de satisfacer esa situación negociada, uno de los productos podría optar por desengancharse de ese componente. Si el nivel de representación buscado es el simplificado, el diagrama anterior nos parece válido, pero si queremos explicitar los componentes de la relación, sugerimos entonces una segunda forma de representarlo, mostrado en la siguiente figura, donde las células de los productos de alguna forma comparten una interdependencia que, al revés de las otras, genera un backlog único a partir de una ceremonia. No debe verse esta como una “reunión”, sino como un mecanismo de alineamiento y negociación, sea el que sea.

Pero no demos mucha importancia a este nivel de detalle. Lo importante de estas estructuras es que la autogestión de todas las células es asíncrona e independiente, y el alineamiento entre las mismas viene dado por las priorizaciones de los elementos de mejora en los distintos backlogs. Así que volviendo a nuestro caso, un subproducto usado por dos o más productos pasará a ser considerado un “componente”, como si fuese un producto interno independiente. Lo representaremos de esta forma, usando dos rayas para indicar que es un equipo que trabaja en un producto interno:

El desarrollo del componente debe basarse más a una relación cliente-proveedor entre los tigres y el resto de productos, pero teniendo en cuenta que hablamos de un componente que consume el cliente final, con lo que el foco deberá seguir estando en él. Su propósito está combinado entre aportar valor al cliente final y aportar valor a los equipos internos. Para ello “desengancharemos” totalmente a los tigres de la estructura de producto, dejando de formar parte de ningún producto en concreto y representándolo como hemos hecho arriba.

No hay que temer que la relación entre estos equipos no sea tan evidente en el diagrama. Por una parte, el uso del componente por parte del producto de los lobos estará bien reflejado en sus mecánicas internas, al igual que lo estarán el uso de componentes comerciales externos a la organización. Por otra, cuando se inspeccione al equipo del componente, quedará bien claro la utilidad de su componente y la satisfacción de sus “clientes” internos.

Pero dando una vuelta de tuerca más, el problema es que una célula podría estar trabajando para varios productos. Las influencias están representadas por líneas. Es este caso, un diagrama representando células que se relaciones con varios productos en liza podría ser esta, usando distintos colores de flecha para distintos productos:

Aquí, los perros forman parte del equipo de producto que lideran los lagartos, que también incluyen a los toros y los ciervos. Pero al mismo tiempo están en el equipo de producto que lideran los lobos, junto con los gatos.

Por último, un producto puede llegar a ser muy complejo y contar con innumerables células de trabajo. En estos casos nos encontraremos con interdependencias de elementos de producto entre células lejanas. Esto significa que ciertas células trabajando en el mismo producto, pero no relacionadas de forma directa por un artefacto o ceremonia entre si, trabajarán en subproductos o partes del producto que sí que estén relacionados entre sí. Podría darse el caso de que uno requiera estar listo antes de que el otro pueda ponerse en producción, o que en su definición queden establecidos los detalles de funcionamiento del otro. Para la coordinación de todo ello, la propia célula de primer nivel puede establecer un artefacto (cuadro de interdependencias de producto) y establecer una ceremonia (sesiones de coordinación de producto) para minimizar riesgos de coordinación o, en su defecto, crear una célula con tal propósito.

Como mecanismo de simplificación, proponemos otro componente distinto para representar “área” (que no “equipo”, lo cual reservaremos para los productos), escalando en complejidad y obviando los detalles sobre células y cómo se relacionan. Volviendo a nuestro ejemplo, pudiera ser que consideremos como un área el conjunto de células formado por los lobos, los gatos, los perros, los lagartos, los toros y los ciervos. La razón de declarar a este conjunto de células como un único área puede ser puramente organizativa, quizás atendiendo al tipo de productos que desarrollan. Si dejamos como área separada a los tigres y los linces, la forma de representar la simplificación organizativa en áreas sería esta:

En el área liderado por los tigres indicamos con dos rayitas su condición de área que trabaja con un propósito de añadir valor internamente. En nuestro modelo, una célula puede trabajar en más de un producto distinto, pero no puede pertenecer a un área distinta. “área” es sólo un elemento de simplificación a nivel organizativo, donde se hereda todo lo referente a sus células, tanto las maestrías cubiertas por sus miembros, como las carreteras asfaltadas que necesitarían o los umbrales de riesgo que deberían cumplir (estos de forma consolidada o compuesta, según se especifique).

A nivel de área puede que queramos añadir más información sobre el modelo que estamos pintando. Quizás a este nivel de escalado queramos especificar las mecánicas de motivación extrínseca que afectan a sus células para promover los patrones que promovemos en el ecosistema. Estas mecánicas tendrán sus propias “fichas”, o quizás esquemas particulares, ya que podrán ser en sí muy complejas y además de naturaleza tan diferente unas de otras que representarlas de una forma uniforme resultaría complejo y aportaría poco valor. Lo importante es saber cuales son y qué comportamientos promueven.

Pero también podemos buscar una vista de nuestra organización desde el punto de vista de producto. La representación del ejemplo anterior sería esta:

Si expandiéramos el producto liderado por los lobos, de color azul, nos encontraríamos obviamente además con las células de los gatos y los perros. Esta última también aparecería si viésemos el interior del producto rojo, el liderado por los lagartos, porque trabaja en los dos productos diferentes, junto con los toros y los ciervos. Las células de nuestro componente liderado por los tigres, el de color verde, serían por supuesto los mismos tigres y los linces. En este caso, a diferencia que con las áreas, podemos llamar a cada producto haciendo referencia a la célula de ideación de primer nivel, ya que es única.

A este nivel deberíamos también definir un propósito global del equipo. Podríamos decir que este es el propósito compuesto y alineado resultante de todas sus células, pero en realidad sería al revés. El propósito a definir originalmente debería ser el del equipo (de producto), y luego los propósitos de cada célula debe ser definidos con objeto de alinearse con el del equipo. En realidad, si lo pensamos en un contexto de crecimiento desde su origen, el propósito del equipo será el mismo que el de la célula embrionaria. Luego, cuando esta tuvo que dividirse en dos, la de primer nivel (o más de ideación), redefiniría su propósito para concretar su aporte al propósito global. Lo mismo haría la célula de segundo nivel. Así, conforme el equipo va creciendo con nuevas células o dividiendo las existentes, los propósitos de estas irán adaptándose a la nueva situación, siempre buscando el propósito común de equipo que se había definido. Si por un cambio de estrategia, o de adaptación al medio cambiante, el propósito del equipo cambia, todas las células del equipo deben reconsiderar sus propósitos, así como las maestrías requeridas, las interdependencias con otras células, etc.

¿Y como encajan aquí los modelos SAFe o LeSS de escalado de Scrum? Pues son perfectamente compatibles. Si algún caso una organización prefiere implantar un modelo SAFe para un producto, subproducto o componente en concreto, en lugar de este modelo asíncrono más generalista, podrá hacerlo. De hecho, si retorcemos un poco los modelos, podríamos representar en detalle con estos diagramas equipos que trabajen en LeSS, SAFe o cualquier otro marco metodológico, porque ACF es un marco organizativo e independiente del marco metodológico subyacente.

11.6 Coexistencia con la Empresa Jerárquica

La coexistencia de los equipos de producto con la estructura jerárquica es quizás la más fácil pero la más crítica en cuanto a obtención de resultados. Pensamos así, porque estos equipos son fáciles de delimitar, aunque estén compuestos por recursos a tiempo parcial, y porque su propósito está mejor definido. Aún así, estos equipos y sus células se verán sometidos inicialmente a multitud de interdependencias con áreas de la empresa que, ni son Agile, ni entienden lo que esto significa, o incluso lo ven como una amenaza para ellos y perjudicial para la empresa. Para conseguir el éxito, la integración vertical de los equipos de producto es el mejor camino. En lugar de buscar que todos los equipos de desarrollo sean Scrum, por ejemplo, es más fácil buscar que un producto sea totalmente Agile desde su ideación hasta su puesta en producción. La razón para ello es que esta integración hace disminuir las interdependencias que dificultan la entrega iterativa y continua de valor y, por tanto, el mantenerse centrados en aportar valor al cliente.

Del mismo modo recomendamos eliminar, siempre que se pueda y desde el principio, las interdependencias de servicios que no estén relacionados con los umbrales de riesgo establecidos como límite y que, sin embargo, estorben o impliquen reducción en el grado de libertad. Por ejemplo, una medida que aporta agilidad manteniendo el control es proporcionar una partida presupuestaria acotada en una cantidad máxima para libre consumo, con un control de su buen uso a posteriori, sin necesidad de aprobación previa.

Al implantar modelos Agile, uno de los inconvenientes más difíciles de vencer que nos vamos a encontrar en las empresas es lo interiorizado y extendido que está en las corporaciones el concepto de proyecto. El concepto de proyecto tiene diversos atributos que contradicen la agilidad. Para empezar, un Proyecto implica tener un principio y un fin, como si tras la fecha límite de cumplimiento no existiera nada más. Por contra, Agile implica un proceso empírico de prueba y error en el que las necesidades de mejora del producto se van decidiendo con el tiempo, y donde el final del desarrollo de un producto coincide con el final de la vida de dicho producto. Sin embargo, puede ser que el esfuerzo semanal requerido para dichas mejoras vaya decreciendo con el tiempo, lo que significará que el equipo de trabajo repartirá sus esfuerzos con algún otro producto nuevo, o que disminuirá su tamaño. En cualquier caso, esto es incompatible con una fecha fija de final de proyecto. Además, un Proyecto implica objetivo cerrado en alcance, mientras que en Agile el alcance varía conforme vayan realizándose entregas parciales que faciliten la toma de decisiones sobre el funcionamiento del producto. Por último, un Proyecto implica un plan prefijado, donde la gestión del proyecto se realiza como una gestión de desviaciones, mientras que agile requiere replanificación constante en un método de gestión donde el cambio no es una desviación, sino que es bienvenido. El cambio de filosofía de pensar en producto en lugar de en proyecto debe comenzar por los individuos que participan en la concepción, por la parte conceptual del equipo. Este cambio de filosofía es crítico y necesario y la integración vertical del equipo en Agile en lugar de aplicarlo sólo al desarrollo facilita la forma de proceder. Pero no bajemos la guardia, porque lo más probable que nos vayamos a encontrar es que todos estos integrantes del equipo vertical pensarán en muchos casos que saben “trabajar en agile”, cuando en realidad sigan imponiendo planes, protocolos internos de trabajo, seudo-contratos entre las distintas etapas y un clima de “cliente-proveedor” entre ideación y desarrollo.

Una forma de proceder a la integración sería que la célula de ideación de primer nivel de cada producto, o el product owner en su defecto, mantenga una interdependencia de alineamiento con el individuo de la estructura jerárquica de quien dependa. Este Jefe debería asumir un rol de supervisión y liderazgo servil en lugar de un rol autoritario, tomando decisiones en el qué y en el cómo que debiliten la autonomía del equipo de producto, al menos en lo posible.

El equipo de producto también sufrirá interdependencias con las áreas de planificación y control, tales como departamentos financieros, mesas de compras, auditoría, control de calidad, seguridad, etc. Estos departamentos imponen normas y procedimientos de obligado cumplimiento. Para facilitar la agilidad en la célula con el cumplimiento de estas normas y controles proponemos la gestión de riesgos por umbrales, como el ejemplo de la partida presupuestaria acotada anterior. Su implantación implica que estos departamentos de control transversales admitan autogobierno de los equipos de producto hasta un umbral de riesgo establecido, el total de la cantidad dispuesta en la partida presupuestaria en el ejemplo anterior, algo que debe ser razonable para mantener un riesgo controlado, pero con un mínimo de agilidad en los equipos.

Este proceso de rebajar la rigidez de las interdependencias es largo y requiere un cambio cultural importante en la empresa, consistente en entregar confianza para recoger compromiso. La desconfianza absoluta que reina en las grandes corporaciones será combatida con el acercamiento de las funciones de la Propiedad por parte de las células del Agile Board, pero esto llevará su tiempo. Mientras tanto, los equipos deberán aprender a subsistir en este ambiente hostil a la agilidad.

Finalmente tendremos las interdependencias con áreas de servicios internos, algunos de los cuales coinciden con los de planificación y control, tales como sistemas, recursos humanos, facility management, compras, etc. Estos servicios suelen ser de obligado consumo en las corporaciones con objeto de lograr sinergias, mejores prácticas y eficiencias. Sin embargo, precisamente su obligado cumplimiento suele derivar en unos servicios que, aun siendo de calidad, no están orientados al cliente y no son proporcionados en la forma y con el alcance que los equipos requieren.

En la AEZ recomendamos liberar desde el inicio a los equipos de la obligación de utilizar estos servicios, siempre y cuando cumplan con los umbrales de riesgo establecidos. Al mismo tiempo incluiremos en la estrategia de agilidad la conversión de estos servicios a paved roads para garantizar que sigan siendo consumidos, o que vuelvan a serlo, por los equipos agile. Es un sacrificio de la eficiencia en favor de la agilidad que será muy fácil de entender si hemos elegido adecuadamente los equipos que deben ser Agile. Veremos, en contra de lo previsto pero demostrado por la experiencia, que la conversión de servicios sinérgicos internos en paved roads conlleva una gran motivación en los equipos encargados, quizás debido al orgullo del trabajo bien hecho. Sobre las Áreas de Expertise

12 Sobre la organización del Área de Expertise

12.1 Introducción a las Áreas de Expertise

Ya hemos comentado que los equipos de las áreas de expertise (AE) se centran en facilitar la generación de valor del resto de áreas, con lo que su estructura organizativa y funciones estarán construidas pensando en las células del resto de la organización como sus propios clientes. La gran diferencia entre las células de esta área con las del área de producto, es que los servicios que ofrecen no son consumidos por el cliente final.

Por lo demás, hay muchas similitudes entre unos y otros, las cuales mencionaremos, pero sin volver a entrar en sus detalles. Para empezar, estos equipos son propietarios de sus servicios. Su libertad es también casi absoluta en definir el propósito en el que trabajan, decidir cómo se autogobiernan o qué maestrías necesitan y cómo las van a conseguir. Sólo los mecanismos enfocados a promover patrones clave a nivel global, así como es cumplimiento de los umbrales de riesgo, limitan dicha libertad, ya que las interdependencias establecidas para fomentar la agilidad y el liderazgo también quedan en este caso muy alineadas con su condición y, por tanto, no coartarán su agilidad. Todo esto es por tanto idéntico a lo dicho para el área de productos.

Pero hay una diferencia derivada de no trabajar en productos o servicios dirigidos al cliente final, ya que, al no generar un valor tangible en términos económicos o como indicadores de mercado, se requiere en. muchos casos una valoración cualitativa para su seguimiento que además depende de forma muy subjetiva de la percepción que tienen las células que consumen el servicio, que además de ser clientes son colegas, para bien o para mal.

Los equipos que forman las áreas de expertise tienen como objetivo dinamizar la mejora continua de la organización, aportando sinergias mediante los paved-roads, que aportarán una ventaja competitiva a los equipos de producto frente a startups y empresas medianas. En realidad esto hace que sólo tengan sentido en grandes corporaciones, ya que para una empresa mediana o startup será muy complejo encontrar este tipo de sinergias dentro de sus pequeñas organizaciones. En estas empresas, el resto de funciones que ahora veremos tendrán que ser asumidas por las propias células del área de producto.

Las células que trabajan en el AE, también pueden estar relacionados con los umbrales de riesgo establecidos, no sólo porque tengan que cumplirlos, sino porque, aunque no sean los encargados de definirlos, serán probablemente los encargados de dar servicios tanto para medirlos como para facilitar su cumplimiento al resto de las células. Es decir, algunos de los paved-roads que ofrecen serán servicios que facilitan el cumplimiento de los umbrales de riesgo.

Pero sobre todo, la función de estas áreas de expertise es la que da razón a su nombre: fomentar las maestrías que se consideran claves en la organización. Cuando pensemos en estas maestrías, no debemos pensar sólo en materias relacionadas con técnicas o tecnologías punteras como bigdata, blockchain o Internet of things, que podría darse el caso, sino también en maestrías clásicas como saber comprar, saber reclutar nuevos miembros, asegurar la calidad del producto, sobre medidas de la seguridad de la información, asesoría legal, etc.

En realidad, nosotros vemos la generación de maestrías y la creación de sinergias como dos perspectivas de la misma cosa. En un enfoque lean, debemos poner esfuerzo sólo en lo que aporte valor. Una organización debe crear servicios internos sólo porque crea que aportan un valor definitivo. Todo lo que aporta valor directamente sobre el producto, como su definición, su desarrollo, su despliegue u operación pertenecerá al equipo de producto, aunque hemos visto que también ahí hay sinergias creando “componentes”. Fuera nos quedan cosas como “gestión de recursos humanos (RRHH)”, la cual vamos a usar como ejemplo para esta reflexión. Por una parte podemos determinar como gestión de riesgo crítico algunos factores de la contratación. Nadie mejor que los integrantes del equipo de producto para determinar si el potencial colega tiene las maestrías y capacidades necesarias para su trabajo. Delegar esa faceta a un departamento central de RRHH es un error. Sin embargo, hay otras características del candidato que nos preocuparán, como lo alineado que esté con los valores que perseguimos, si es o no potencial causante de problemas, si tiene problemas con la sociedad, o incluso si legalmente puede o no ser contratado. Las maestrías necesarias para cubrir estos riesgos de contratación son muy complicadas de tener en todas y cada una de las células de producto. Por tanto, debería existir un área de expertise relativa a RRHH que ofrezca servicios que cubran desde la función de captura de información y contacto con candidatos hasta determinar la viabilidad de su contratación (cumplimiento de los umbrales de riesgo por parte del candidato), pero la decisión final sobre la adecuación del futuro colega a las necesidades por cubrir de la célula debe recaer en sus miembros, con la ayuda inestimable del coach que ofrecerá una visión periférica y objetiva que ayudará a la célula. Resumiendo, la necesidad de una maestría a nivel global que por su especialización resulta complicada de tener en cada célula, como la relativa al reclutamiento de candidatos, es una sinergia requerida y bienvenida que debe ser proporcionada por un paved-road.

Todo lo dicho para las células de área de producto relativo a su gobierno, en cuanto a patrones, liderazco, agilidad y alineamiento, es aplicable a las células del AE. Sólo destacar que son protagonistas en cuanto al ofrecimiento de los paved-roads que los primeros consumen para su alineamiento.

12.2 Estructura de la AE y su representación

La relación entre servicio y células en el AE es idéntica al de producto y células en el área de productos (para simplificar el lenguaje, cuando nos refiramos al AE nos referiremos a “servicios”, mientras que cuando lo hagamos al área de productos hablaremos de “productos”, si bien un área de expertise podría ofrecer como paved-road un producto, y la organización puede estar ofreciendo a sus clientes servicios). Cómo se componen las células desde el individuo es idéntica y por tanto las fichas que las documentan son similares. También la gestión de la mejora continua y sus relaciones con coaches y angels.

Sin embargo, hay algo especial que quizás hasta ahora ha pasado desapercibido por el lector, ya que cuando nos referimos al área de producto hablamos en singular, toda ella compuesta por equipos de productos independientes, mientras que cuando hablamos de áreas de expertise hablamos en plural, como si hubiera varias. En realidad, concebimos varias áreas de expertise donde internamente pueden existir distintos servicios independientes en cada área, todos ellos relativos a un mismo ámbito. Por ejemplo, podemos tener el área de expertise de RRHH, con servicios de reclutamiento y de formación independientes. Cómo organizar estas áreas es función del agile board. La cuestión es que al tener varios servicios independientes, pero pertenecientes al mismo ámbito, pudiera darse el caso en grandes corporaciones que se requieran equipos de células también independientes, viendo la necesidad de la existencia de una célula de primer nivel dentro de cada AE que realiza funciones similares a la del Agile Board, pero aplicadas sólo al área, como si de una empresa aparte se tratase. Lo vemos como una forma de generar una sinergia en labores de ideación de los servicios. A efectos prácticos, la creación de un AE es una decisión del agile board que quiere promover servicios sinérgicos en un determinado ámbito, creando una célula de primer nivel para el área encargada del alineamiento de la ideación de todos los servicios pertenecientes a ese ámbito. Esta célula identificará los servicios potenciales a ser ofrecidos como paved-roads dentro de su ámbito, analizará la viabilidad de dichos servicios, los propondrá al agile board para su aprobación y arrancará su ideación y desarrollo dentro de la propia célula, asignándolo a una célula de segundo nivel ya existente dentro del AE, o creando una nueva célula para tal servicio.

En cuanto al funcionamiento/escalado de la estructura de cada uno de los servicios es idéntica a la de los equipos de productos. Presentarán estructuras similares, si bien como vamos a ver por la naturaleza de los paved-roads, nunca deberían llegar a ser tan complejas como las estructuras de producto. Como es lógico, también un equipo de servicios puede gestionar y mantener varios de ellos a la vez.

La representación es similar a la usada en productos. Imaginemos que hablamos de un área de expertise de dos células que ofrecen tres servicios o paved-roads a la empresa. Lo dibujaríamos así, independientemente del número de paved roads que ofrezca:

Las dos rallitas indican que es un servicio interno, como indicaban en el caso de los componentes. La ficha de estas células tendrá un apartado especial, aquel que especifica los paved roads que ofrece. Cada paved-road tendrá su ficha particular, pero eso lo veremos más adelante.

Si los osos en realidad forman parte de un área de expertise, gestionada por las ranas, donde un equipo diferente, los azores, ofrecen otro conjunto de servicios, la representación sería así:

El equipo de un área de expertise lo representaremos de la misma forma que el equipo de componentes, con sus dos rallitas correspondientes. En este caso también documentaremos su ficha, que expresará los paved-roads que son ofrecidos por el área de expertise en cuestión.

Pero si fuese una estructura muy compleja dando servicios internos también complejos para una gran corporación, podría descomponerse internamente en varios equipos (de paved-roads) o varias áreas. Imaginemos un área de expertise de recursos humanos centralizada para una gran corporación financiera internacional. Hablaremos entonces de diversas células, algunas de ellas muy especializadas, ofreciendo servicios de reclutamiento muy globales y formación en áreas muy diversas. Podría queda así el AE de RRHH que lidera las ranas:

En cualquier caso, si representamos el detalle interno del AE o no, dependerá del propósito de nuestro análisis como agile coaches o como corporate angels.

Sería fácil que se de el caso de que un célula trabaje en dos paved-roads, o que en un paved-road trabajen dos células debido a su tamaño. Tendríamos por tanto la misma circunstancia que la mostrada en los ejemplos de escalado y complejidad mostrado en los productos, pero esto será muy poco frencuente ya que, como veremos, una condición de éxito del servicio de paved-road es su simplicidad.

12.3 Qué son los Paved Roads o Carreteras Asfaltadas

Pero llevamos un tiempo hablando de paved-roads y aún no hemos dicho qué son o qué tienen de especial. El concepto es muy simple. Un equipo Agile es autónomo y por tanto libre para llegar al objetivo por donde quiera. Libre para elegir un propósito como su destino, entendido como la intención de hacer lo que hace. Libre para decidir la forma de llegar a confeccionar su equipo, autónomo para decidir la mejor gestión que debe aplicar para conducir su trabajo. Autosuficiente, con maestrías, con el deseo de ser mejor y mejor en algo que importe.

Sin embargo, cuando una empresa tiene numerosos equipos de trabajo, es normal que algunos de ellos empiecen a transitar metafóricamente por los mismos caminos, usando las mismas arquitecturas, necesitando las mismas maestrías o los mismos servicios. Por ello, la empresa asfaltará carreteras para que queden como una opción para que estos equipos las utilicen para alcanzar sus objetivos de la forma más rápida y eficiente posible. Son carreteras a disposición de los equipos, no son carreteras obligadas para los equipos. Es por tanto una filosofía de implantación de servicios internos para aprovechar las sinergias corporativas sin mermar la agilidad de los equipos ya que estos siguen teniendo la autonomía de hacer uso o no de ellos.

¿Pero podríamos decir entonces que paved-roads son simplemente servicios ofrecidos de forma opcional? Para empezar, eso es un modelo ya muy habitual en las grandes corporaciones, modelo que habitualmente fracasa, con lo que nos referimos a algo diferente. Si, un paved-road es un servicio interno opcional, pero cumple además con varias condiciones que repasaremos en esta sección.

Para empezar, una carretera asfaltada surge por uno de estos tres motivos, cuya existencia debe ser probada antes de la constitución del servicio: la oportunidad de ahorros por economía de escala, la necesidad de una doble especialización o la necesidad de fomentar buenas prácticas.

Para ofrecer claras economías de escala, deben proporcionar una clara ventaja económica frente al consumo descentralizado (servicio de cloud, por ejemplo), pero a su vez estas economías deben ser claras frente a contratarlo a un proveedor externo. Si no es así, la función estará mejor integrada en cada equipo, que lo gestionará a su gusto, o externalizada en proveedores externos que el equipo podrá elegir también a su gusto. La agilidad, en forma de libertad de elección, por parte del equipo de producto debe ser plena.

Si no hay opción clara de economías de escala, el paved-road podrá existir para resolver una doble especialización, en maestría de mercado y en maestría de la corporación. Esta situación es bastante frecuente en grandes corporaciones. Algunas funciones, como la usada de ejemplo para RRHH anteriormente, requiere dominar bien la maestría general, como puede ser el procedimiento de captación de candidatos o la viabilidad legal de las contrataciones, pero al mismo tiempo requiere un grado de especialización grande en su aplicación dentro de la corporación, como entender los valores que se persiguen a nivel empresa, las particularidades sobre las maestrías más generales utilizadas en la corporación, como conocimientos financieros si hablamos de una corporación financiera, como las características específicas que los agile coaches buscan para nuestra organización. Por todo ello, puede ser más conveniente utilizar unos servicios internos de RRHH que delegar estas funciones a nivel global en un proveedor externo, lo cual no significa que el AE encargada se apoye en especialistas externalizados para cuestiones específicas, aunque siempre añadiendo su valor relativo al conocimiento de las particularidades de la corporación. Por tanto, hablamos de combinar la característica de especialización en una materia, con la necesidad de personalizarla a la empresa. Business intelligence podría ser otro ejemplo clásico.

Pero si no hay economías de escala que conseguir, ni necesidad de una doble especialización, aún hay otra razón más para crear una paved-road. Fomentar una buena práctica (que no una mejor práctica) o un servicio crítico considerados estratégicos para la organización. En dicho caso, buscamos servir de palanca o facilitador de la implantación de una práctica que a nivel corporativo se quiere fomentar, bien por considerarse oportuna en cuanto al alineamiento con los valores, o crítica por tratarse de un servicio considerado “core” que proporcionará ventaja competitiva, o porque garantice el cumplimiento de umbrales de riesgo. En cualquier caso, hablamos de un servicio que se considera estratégico. La garantía de accesibilidad de los productos que la empresa ofrece por personas discapacitadas, o los servicios de ciberseguridad, podrían ser dos ejemplos claros de paved-roads considerados estratégicos.

Si no hay una razón clara relacionada con uno de estos tres motivos, conviene dejar los equipos lo resuelvan de la mejor manera según su caso, bien resolviendo ese servicio dentro de su mismo equipo, como podría ser el caso del reclutamiento, o accediendo al mercado en busca de los servicios que mejor se adapten a sus necesidades, caso que podría ser aplicado al ejemplo de la formación.

Y sabiendo ya los tres motivos que fundamentan una paved-road, hablemos de las características que deben poseer para no terminar siendo meros servicios internos ofrecidos por un área funcional dentro de la empresa jerárquica.

Para empezar, y como hemos dicho muchas veces, no son de obligatorio consumo, lo cual puede parecer una herejía para determinados directivos formados en la empresa jerárquica. ¿Quién puede creer que un servicio interno opcional puede generar sinergias? ¡Ni siendo gratuito!

En realidad no es gratuito, aunque hablaremos más tarde del modelo económico acorde a cada tipo de carretera asfaltada. Para quien se haga la pregunta retórica sobre la viabilidad de un servicio interno opcional, la respuesta la tenemos en el cumplimiento del resto de características que vamos a enumerar en esta sección. Pero tiene razón, los servicios internos que las corporaciones de hoy en día ofrecen, o bien son obligatorios, o terminan fracasando porque nadie los consume pagando. Y aquí toca un minuto de reflexión por parte del lector, porque habrá que preguntarse por qué ocurre esto. Si normalmente el potencial cliente no quiere consumirlos, ¿hacemos bien en imponerlos? Obviamente no, a no ser que pensemos que los empleados y directivos que no quieren consumirlos busquen por alguna razón el mal para la empresa, lo cual no suele ser el caso.

Pero siendo opcionales, para que se usen deben ser primero “necesarios”, pero eso será así si hemos aplicado bien el análisis de las tres razones únicas de creación de un paved-road. Segundo, y a diferencia de los servicios internos habituales, tienen que estar construidos como “client-centric”, centrados en el cliente, y el cliente en este caso son los equipos internos de la organización. Aplicando un análisis de gestión del comportamiento humano, sólo serán client-centric si son opcionales, ya que el equipo que trabaja en el servicio debe tener el estímulo de necesitar satisfacer a su cliente para que este no huya. Eso mismo es lo que genera el efecto mágico de motivación intrínseca positiva cuando se logra. Por eso hemos visto que el mismo equipo que trabaja en un servicio interno obligatorio, cuando queremos que pase a ser un paved-road y después del shock, temor y rechazo al cambio, termina estando mucho más motivado una vez que lo consigue. Ahora el fruto de su trabajo es aceptado y bienvenido por sus colegas “clientes”.

Para poder ser client-centric, lo mejor es que los equipos de las AE, a parte de organizarse como células de la AEZ, sean agile en su forma de trabajar y apliquen las técnicas agile establecidas.

Otra característica adicional a los servicios internos habituales que es clave para facilitar su éxito es que sean simples, tanto en su concepción, como en su uso y su producción. ¡Si, vaya descubrimiento!, pero merece la pena destacar la importancia de la táctica KISS (keep it simple, stupid) también en ese ámbito. Cuando los servicios internos son de obligatorio uso, la responsabilidad sobre el entendimiento del funcionamiento del servicio recae en el cliente. Cuando son opcionales, si el cliente no entiende cómo usarlo, abandonará para buscar una alternativa. Si el servicio parece complejo, la célula de ideación del servicio debe intentar desintegrarlo en partes o aplicar la regla de Pareto, centrarse en el 20% de la funcionalidad que ofrece el 80% del valor.

También debe ser simple en su despliegue y operación. De lo contrario, debe ser un servicio muy core o estratégico para añadir esta gran carga en la organización, la cual debe centrarse en aquellas cosas que generan ventaja competitiva, y no enredarse en problemas complejos por tal de generar cierta sinergia o economía de escala (a no ser que esta sea tan grande que pase a ser estratégica, claro).

La clave de qué las carreteras asfaltadas y el modelo en general funcione es que se aplique siempre un enfoque muy conservador en cuanto a la creación de estos servicios, desarrollándolos sólo cuando estén bien claros sus beneficios y su viabilidad, y siendo exquisitos en su diseño con la preservación del autogobierno de las células que los van a consumir. Si algo de esto no está claro, deleguemos mejor en los equipos para que resuelvan sus propias necesidades, bien sea resolviéndolas internamente o accediendo al especialistas del mercado para buscar la opción que mejor se adapte a sus necesidades. Pero tengamos presente algo de suma importancia: estos paved-roads son una de las pocas ventajas competitivas que la corporación tiene frente a las startups o empresas medianas con las que compiten. Jamás podrán competir contra la agilidad y capacidad de adaptación de estas últimas y difícilmente podremos promover la innovación por encima del resultante del conjunto de ellas. Sin embargo, la necesidad de la gestión de riesgo global, la necesidad de control sobre el alineamiento con la propiedad, siempre será una desventaja frente a las organizaciones pequeñas. Para cada cumplimiento impuesto de un umbral de riesgo debería existir una paved-road que facilite tanto la medición como su cumplimiento. La existencia de carreteras asfaltadas dentro de la corporación debería tratarse como algo estratégico y core en el desarrollo de nuestro negocio dentro de la corporación.

Pero hay dos factores más que son críticos para el éxito del modelo y que están relacionados con la “transformación”. Asumamos que, si una corporación tiene éxito con un servicio interno optativo por el que cobra sufragando su coste, o bien se parece a una paved-road, o en cualquier caso está satisfaciendo a sus clientes internos con el su modelo, lo cual es ya más que suficiente para se le una AE de la AEZ. Pero lo normal es que nuestras futuras carreteras asfaltadas sean ya hoy caminos tortuosos para el usuario, aunque de uso obligatorio. Es decir, habrá ya equipos encargados de esos servicios y habrá un mecanismo que imponga la obligatoriedad de su uso. Por tanto, nos enfrentamos a cómo transformar el equipo y cómo transformar su implantación como servicio opcional “utilizado”. Porque de nada sirve una carretera asfaltada, si no es transitada frecuentemente por los equipos.

Para responder a la transformación de los equipos, no hay nada nuevo en este aspecto. Es difícil y puede ser doloroso tanto para los integrantes de estos servicios, como para sus consumidores. Aquí también aplica lo de que cada caso es diferente y por tanto aplican distintas soluciones, pero vamos a repasar unas cuantas recomendaciones que podrían aplicar en muchos casos.

Para empezar, debemos aplicar un análisis de viabilidad para dichos servicios como paved-roads repasando si pudieran cumplir los condicionantes y características enumerados en la sección. Puede que de ahí obtengamos la decisión de simplemente liberar el servicio y deshacer el equipo. Pero si dicho servicio cumple una de las razones fundamentales, una opción para su transformación es cambiar primero la organización y la forma de trabajar de los equipos del servicio, inculcando los valores y principios de la agilidad e identificando las maestrías que faltan en dicho equipo para convertirlo en uno agile y client-centric. Cuando tengamos ya iniciado este paso y adelantado algo de terreno, podemos comenzar a liberar de forma gradual a los equipos de producto de su obligatoriedad de uso, induciendo el estímulo de la necesidad de estar centrados en el cliente también de forma gradual. El equipo del servicio, aunque esté organizado ya de la forma adecuada, necesitará grandes dosis de coaching, con lo que una célula de agile coaches deberá estar dando soporte continuo. Si todo va bien, dicho coaching podrá ir remitiendo para que sean las propias células de la AE las que vayan adaptándose a la nueva situación.

Durante el paso de obligatorio a opcional, la figura de los maestros juega un papel fundamental, y en dos direcciones distintas. Las células de los equipos que tienen necesidad del servicio también necesitarán tener una maestría para usarlas. Las propias AE deben formar a dichos maestros en caso de no existir. En cualquier caso, estos maestros deberán ser por una parte bien escuchados a la hora de perfilar el servicio que sus células van a consumir (que mejor forma de quedar centrados en el cliente) y por otra deberán estar bien informados de las ventajas que estos servicios aportan: sus economías de escala muy competitivas respecto a las encontradas en el mercado, reflejadas en el precio del servicio, el aporte de doble especialización, difícil o imposible de encontrar en el mercado y caro de tener en cada célula, o estar basada en una buena práctica que ayudará a cumplir un umbral de riesgo, cuyo cumplimiento implica un alineamiento con la propiedad y que será más fácil de cumplir usando el servicio prestado que con cualquier otra alternativa. Todo esto deberá ser verdad para que tenga el efecto deseado y no sólo un cuento comercial interno. Los maestros detectarán rápidamente las debilidades del sistema y los incumplimientos de expectativas, pero también sus ventajas y fortalezas, siendo los mejores embajadores para liderar su uso en sus equipos respectivos.

Y todo será más fácil si también se hace visual. La existencia de un catálogo de servicios del AE sería de mucha ayuda, no sólo para fomentar su uso dentro del ecosistema AEZ, sino también para que sean usados por el resto de equipos del área jerárquica, cosa que veremos en la sección que cierra este capítulo.

12.4 Modelo Económico y “fiscal” para las Paved Roads

Cobrar por los servicios internos es una práctica ya muy habitual en las grandes organizaciones por ser muy de sentido común. Parece una forma saludable para la empresa que la forma de costear un servicio interno sea que el usuario pague por él. Esto sigue siendo aplicable en el ecosistema agile, pero así como, normalmente, el precio y el modelo económico se determina desde el punto de vista del “proveedor”, en la AEZ debe determinarse según el propósito global del ecosistema. Es decir, cuando montamos un paved-road lo hacemos por el bien común y, por ende, por el bien de los equipos de producto. Por tanto, el modelo debe compatibilizar ambas cosas. No puede ser beneficioso para el global, pero perjudicial para el que lo usa, ni viceversa. Así que el modelo que le asignemos a los servicios será crítico para su éxito. No será igual que apliquemos un pago por uso, una cuota fija o un precio subvencionado. Si adoptamos un modelo económico muy favorable para el equipo consumidor, puede que estemos dopando el servicio favoreciendo a los equipos de producto pero perjudicando a la empresa en su globalidad si se tratase de un servicio que no se mantiene económicamente. Si por el contrario adoptamos un modelo económico que no sea interesante para el consumidor, penalizaremos su uso opcional frente a uno similar ofrecido en el mercado.

La elección del modelo dentro de la gran diversidad posible a aplicar deberá hacerse según el tipo de servicio y la fase de su implantación. Centrémonos primero en el análisis según el ciclo de vida del servicio desde su concepción a su implantación. Para ello debemos de considerar un mecanismo fiscal, es decir, de gestión centralizada de haberes y bienes, y su mecanismo de recaudación de impuestos, que subvencione la fase de inversión requerida para cualquier innovación o implantación de mejora, y en este caso la de estos servicios internos opcionales.

Lo mismo que hemos dicho para el modelo económico, podemos decir para el modelo fiscal. Debe ser un modelo justo para todos los equipos y beneficioso para la organización. Su administración quedará delegada a las células del agile board. Por norma general, no podremos exigir a los equipos de la AE ofrecer un servicio adecuado sin ningún tipo de subvención. Necesitarán equivocarse durante un tiempo, tendrán costes fijos que difícilmente podrán ser sufragados por los pocos clientes iniciales. Para el agile board, un AE es como una startup interna con una misión, pero con unas fases iniciales que deberán ser financiadas a riesgo. Al igual que una startup, deberá mostrar transparencia a sus inversores, deberá ser inspeccionada de manera continua y se adaptará a las nuevas estrategias buscando un modelo de negocio viable. Pero su “modelo de negocio” no será relativo sólo al aspecto económico, sino que formarán parte de él todos los elementos que generan valor para el propietario, que también es el cliente. Es por este preciso motivo que los equipos de estos servicios lo tienen más fácil que si fuese un startup en cuanto a probabilidades de éxito, ya que se encuentra ante un nicho con necesidades y características muy parecidas y a la vez sinérgicas con las del propio equipo de la AE. La desventaja obvia es que, al tratarse de un nicho muy acotado, su crecimiento también será limitado por el tamaño de la organización. Si uno de estos servicios internos funciona extremadamente bien, podríamos tener la fantasía de hacer un spin-off y convertirlo en un startup libre de dar el servicio a clientes externos, fantasía muy habitual incluso en los cuerpos directivos de corporaciones jerárquicas con servicios internos obligatorios. Pero hay que tener cuidado, porque podría ser un error y, ganando un spin-off que genera ingresos, perderíamos un paved-road teniendo que reinventarlo de nuevo. Como hemos dicho, el modelo de negocio que buscan los equipos de las AE no es comparable al de una startup, ya que en la aportación de valor a sus propietarios, suman componentes que facilitan la consecución del propósito global de la corporación, de importancia en ocasiones mucho mayor que la propia aportación del margen económico por una buena gestión.

Con esto, casi hemos dicho todo, pero analicemos distintos modelos según la naturaleza del servicio y, para ello, empecemos por el más sencillo, el de aquellos paved-roads que buscan una economía de escala, en cuyo caso el modelo de negocio buscado debe ser bien claro: el coste total del servicio proporcionado por el equipo a la larga, repartido entre los clientes internos, debe ser sustancialmente menor que la suma del coste de proveedores externos contratados por separado, o desarrollar el servicio dentro de cada uno de los equipos.

Si el modelo “encontrado” se basa en una tarifa plana o en pago por uso, eso es algo que dependerá de cada caso. Se buscará lo más justo y que mejor funcione.

Un primer servicio sencillo de este tipo podría ser el organizar una compra grupal, o negociar con un proveedor unos precios competitivos gracias a la compra por volumen (de toda la corporación). Si la rebaja obtenida compensa el esfuerzo empleado, tanto en el análisis de las necesidades de los equipos cliente, como la manera en la que coartará su agilidad (para ser client-centric), así como el esfuerzo extra de negociación y, finalmente, la gestión de la disposición y consumo del servicio por parte de los equipos, entonces valdrá la pena crear este simple marco de contratación global de los servicios de un proveedor externo. Pero muchas veces esto se hace y su consumo se impone sin realizar esta valoración previa. ¡Hemos conseguido un 10% de rebaja adicional a lo que podría conseguir un equipo por separado! Si, pero han incurrido en un gasto para hacerlo y has establecido una dependencia de los equipos con el uso del servicio por parte de ese proveedor que probablemente genere muchos más gastos como efecto colateral de la imposición en caso de no ser el más adecuado para cada uno de ellos.

Los servicios de gestión de inmuebles y servicios generales podrían ser un buen ejemplo de paved-roads de economía de escala, siendo además buenos canales para mecanismos que generen patrones deseados. Si quiero que la gente se reúna, ofreceré salas de reunión o, mejor que eso, espacios de trabajo que permitan reuniones espontáneas. Si quiero fomentar las relaciones interpersonales, eliminaré mamparas y ofreceré zonas comunes con mobiliario que favorezca la conversación.

Pero tendría que cumplir todos los condicionantes de una carretera asfaltada, incluyendo opciones alternativas a las soluciones aportadas y un servicio centrado siempre en el cliente interno, no sólo en lo que dice la propiedad (la dirección en la empresa jerárquica, que es quien transmite los intereses de la propiedad). Hemos visto muchas barbaridades desde estos departamentos contra la innovación y el desarrollo de dinámicas de equipo, como paredes pulcras que cuidan muchísimo el diseño, pero que prohíben pizarras o tableros kanban en toda la oficina, o disposición de puestos de trabajo para que ningún empleado levante la cabeza de su ordenador.

Pasemos a un segundo bloque, a los servicios que cubren la necesidad de una doble especialización, por una parte en la técnica o tecnología necesaria para el servicio, por otra el conocimiento de las características y condicionantes comunes en los equipos de la organización. Estos aportan un valor difícil de conseguir por los equipos de forma independiente. Lo harán, pero invirtiendo tiempo y esfuerzo en algo que, aunque fundamental, no termina de ser core para su negocio. Imaginémonos el cumplimiento de la normativa de GDPR (Reglamento General de Protección de Datos). Alguien podría pensar que para no limitar su agilidad, cada equipo podría consultar a un especialista en GDPR, que los hay a toneladas, para que este le haga una consultoría ad-hoc. Pero pronto averiguarán que realizar la consultoría de forma rigurosa implica un esfuerzo enorme en transmitir al especialista la naturaleza y los detalles de nuestro negocio. Además, GDPR no es una cosa de un solo esfuerzo, sino que conlleva un día a día importante. Sería mucho más natural que, desde una posición especializada en GDPR, pero también conocedora en profundidad del negocio, la aplicación específica de la normativa a la naturaleza del mismo y dominando los umbrales de riesgo que la propiedad quiere asumir, este servicio sea interno y común para todos los equipos. Las sinergias y la mejora en la gestión del riesgo resulta obvia, la cuestión es hacerlo sin que reste agilidad, o restando lo mínimo, mediante una carretera asfaltada.

Será probablemente fácil que el coste interno de este servicio esté por debajo del mismo servicio proporcionado por un interno (gracias a la sinergia). Por tanto, aunque subvencionemos inicialmente este tipo de paved-roads, deberíamos exigirle pronto que “vuele solo”, sin dopaje financiero.

Finalmente tenemos el grupo de los que cubren la necesidad de fomentar buenas prácticas en la organización. Vimos que los basados en economías de escala, los del primer grupo, pueden necesitar poca motivación extra para su uso cuando ya de por sí ofrecen verdaderas ventajas económicas. También hemos visto que los del segundo grupo, los que ofrecen doble especialización vistos en el párrafo anterior, también necesitan poca motivación extra para su uso debido a la complejidad de encontrar este tipo de servicios fuera. Sin embargo, vamos a ver que estos del tercer grupo necesitan una motivación extra.

La razón es que son buenas prácticas que la organización quiere promover pero que normalmente no son críticas para el equipo y además pueden obviarse. Es decir, aquí la alternativa no es salir a comprarlo a un proveedor externo, sino simplemente no hacerlo. Imaginemos la recomendación de hacer un análisis de riesgos operacionales, incluido ciberseguridad, antes del diseño de un producto. Será normal que el equipo procrastine dejando para el final ese engorro. Es evidente que podemos establecer un umbral de riesgo límite, coartando la agilidad del equipo lo mínimo, que dé libertad para afrontar la tarea cuando el equipo lo vea más conveniente. Pero para evitar que quede al final sin hacer, deberíamos proporcionar al mismo tiempo un servicio de asesoramiento que facilite la acción y dé soporte a dicha tarea. Este servicio deberá estar subvencionado para aligerar al máximo al equipo del producto de cargas en su desempeño.

Una start-up no tiene ese lastre, no necesita gestionar riesgos operativos a ese nivel porque no tiene mucho que perder. En la gran corporación, nuestro equipo de producto necesita competir con esta start-up, pero no puede obviar la carga de la gestión del riesgo que evite causar daños colaterales al resto de la empresa. Es por eso que el agile-board debe decidir aligerar dicha carga para que pueda competir en igual de condiciones con la Start-up, facilitando el servicio y subvencionando su uso. Este coste extra para la corporación debería estar compensado gracias a las sinergias recogidas con otros paved-roads.

12.5 Coexistencia con la Empresa Jerárquica

Un problema que podemos encontrar a la hora de implantar paved-roads en la empresa jerárquica es la forma de buscar compatibilidad a nivel operativo. Si hablamos de un nuevo servicio, que no reemplaza a uno ya existente dado por un área funcional interna, la cosa es fácil, ya que lo diseñaremos de forma que satisfaga las necesidades de los equipos agile sin tener en cuenta al resto de la empresa. Pero hay que tener en cuenta dos consideraciones.

Primero, un paved-road que hagamos para los equipos agile va a ser también válido para el resto de equipos de la empresa jerárquica.

Segundo, será difícil que esta necesidad no esté ya satisfecha por un área funcional existente, aunque no sea ofrecido como un paved-road. Y es que la mayor dificultad que existe de convivencia de la AEZ con la parte jerárquica de la empresa es la relación que los equipos Agile mantienen con las áreas funcionales cross (compras, recursos humanos, IT, etc.). La mayor dificultad para conseguir que los servicios de estas áreas transiten para convertirse en una paved road es la falta de orientación al cliente que solemos encontrar como punto de partida. Esto está motivado por la obligatoriedad del uso de sus servicios, lo cual queda en un puro voluntarismo de las personas que componen los equipos. Cuando comenzamos en el tránsito de un servicio a una paved road, debemos empezar por aplicar Agile en el equipo encargado de idear, desarrollar y operar el servicio, y así pasará a formar parte de la AEZ. Aquí, la transformación del servicio del área funcional por un paved-road es buena para todos, no sólo para los equipos de la AEZ, ya que, de hecho, lo normal es que al estar orientado a aportar valor a los equipos internos como si fuesen clientes externos, sea mejor que el proporcionado por un área funcional que se ve a sí misma como la responsable absoluta en lo que respecta a la materia de la que provee el servicio. Por tanto, una paved road no sólo es una forma eficaz y eficiente de crear una sinergia con los equipos Agile, sino que su transformación también resulta beneficiosa para su consumo por el resto de áreas de la parte jerárquica de la empresa. Es decir, su función y su servicio es cross a toda la empresa.

Pero, ¿cómo la integramos en la organización jerárquica preservando al máximo su agilidad? Lo haremos mediante una relación de interdependencia gestionada entre la célula de ideación de primer nivel y un responsable del área funcional. Obviamente, esta independencia constará al menos de un artefacto y una ceremonia. El primero podría ser un backlog que representara la lista de logros que marcan el propósito de dicho paved-road. El responsable de quien depende el servicio deberá intentar proporcional la máxima autonomía posible a dicho equipo funcionando como un líder servil que usará su autoridad en la empresa jerárquica para eliminar obstáculos del camino.

Cuando disponemos de un conjunto de servicios relacionados con una maestría, o cuando un área funcional completa basa sus servicios en paved roads, debería cuestionarse hacerla transitar de un área funcional a un área de expertise, pasando a ser gobernada por la célula de primer nivel del área, adoptando las funciones de gobierno anteriormente mencionadas y reportando, bien a un miembro directivo de la empresa jerárquica, bien a una célula de corporate angels de la AEZ mediante las interdependencias pertinentes, situación en la cual ya consideraremos al área de expertise como parte de la AEZ. Esta es una forma gradual de ir construyendo las áreas de expertise y de irles dotando cada vez de mayor autonomía y agilidad sin correr riesgos.

13 Sobre Agile Board

13.1 Introducción al Agile Board

El Agile Board está centrado en crear valor al accionista. Es obvio que la creación de valor para el cliente, llevada a cabo por los equipos de producto, revierte normalmente en beneficio para el accionista. Pero como ya hemos apuntado en varias ocasiones, esto no siempre tiene que ser así. En startups o empresas medianas el accionista está muy próximo a los equipos de producto, con lo que el alineamiento de estos con los intereses de la propiedad ocurre de forma natural. Pero en una gran corporación podríamos tener equipos que adopten decisiones que son muy propicias para ellos pero que generen un riesgo para el resto de la organización. Imaginémonos un área de marketing departamental fomentando las ventas comunicando de forma agresiva para cumplir sus resultados dañando la imagen que se busca para la corporación en su conjunto, o adoptando posiciones financieras arriesgadas, u obviando medidas de seguridad para ahorrar costes. En realidad podríamos identificar infinitos ejemplos donde los intereses para un equipo no sean cien por cien compatibles con los intereses del conjunto y, en particular, con los intereses de la propiedad.

El Agile Board de la Agile Corporation debe asegurar el alineamiento, pero cree también en los beneficios que tiene la agilidad en los equipos de producto y, por tanto, sabe que debe optimizar el grado de libertad de éstos a la hora de establecer interdependencias. Tendrá muy en cuenta la madurez de los equipos para determinar el grado de autonomía deseado. A más madurez, es posible más autogestión y se consigue más agilidad. Por lo tanto, como siempre, no se trata de aplicar recetas fijas o de implantar ciertos artefactos y ceremonias específicas, sino que es una tarea de gestión donde hay que diseñar las relaciones de alineamiento dependiendo de la naturaleza y características de cada caso.

Pero veamos qué es el Agile Board, que se encarga de todo lo que no esté directamente relacionado con los productos, o con los servicios internos que faciliten dichos productos, y que gobierna definiendo funciones, dotándolas de recursos y creando interdependencias. El desarrollo de las competencias individuales y de las emergentes a nivel equipo es también una de sus funciones. Así pues, es natural que esta área tenga un rol transcendental en la empresa. El Agile Board no es un sistema jerárquico, sino que será, como todo en la Agile Corporation, un conjunto de células con propósitos particulares y con interdependencias entre ellas y las del resto de la organización.

Como esta área es la que gobierna el conjunto, es normal que su función se realice analizando las cuatro perspectivas diferentes expuestas en el modelo para el gobierno:

• La determinación de los patrones que buscamos repetir en la empresa

• El liderazgo o desarrollo de la perspectiva del yo en el ecosistema

• El alineamiento de las funciones en cada área organizativa

• La agilidad requerida en los equipos

13.2 Gestión del Modelo fiscal

Una empresa que no cambia y no recibe estímulos del exterior, se acomoda, se inventa actividades no productivas para cubrir su tiempo. En ese caso, el propósito intrínseco para el individuo y para el equipo gana peso en el propósito final, desalineándose de la aportación de valor al cliente o de la persecución de los intereses de la propiedad. Esto es algo que las células del Agile Board deben tener presente, estar vigilantes y resolver de una forma ágil, sin mandatos, pero con estímulos para cambiar el comportamiento.

Para gestionar un sistema complejo, el Agile Board debe obviar los detalles. En este sentido, el Agile Board es un facilitador, aparte de coordinar el alineamiento global. De cualquier otra forma, los detalles, el micromanagement, le llevarán con seguridad a tomar decisiones erróneas.

Corporate Angels

• Tienen delegadas las funciones de la Propiedad

• Se centran en lo estratégico, en el alineamiento y en el control

Agile Coaches

• Son los maestros de la agilidad y la promueven a todos los niveles

• Se centran en el método

13.3 Funcionamiento de la Relación entre Células

El gobierno del detalle está delegado a las células de trabajo, así como la estrategia global de producto a los equipos de producto. Por tanto, una célula de angels o de coaches puede dar soporte a bastantes células de trabajo, con lo que el número de las primeras será muy bajo con respecto al número global.

Por ello, aunque representamos árboles de células en el Agile Board, dicha estructura será mucho más simple de lo que se pueda pensar.

13.4 Relación entre Células de Corporate Angels

La primera célula es la Golden Cell o célula oro, donde la propiedad debería tener participación, lo cual es parecido al tradicional board of committee.

El modelo a partir de esa Golden cell dependerá de cada situación. Un modelo entendible es que en dicha Golden cell existan miembros encargados de transmitir el alineamiento a las células del agile board de primer nivel. Si fuera sólo un miembro el encargado de tal propósito, es como si el tradicional CEO fuera como el product owner de las células de primer nivel (de su comité de dirección).

No obstante, las similitudes con la empresa jerárquica tradicional no van mucho más allá, ya que este comité de dirección no sería la representación por parte del director de cada uno de los distintos departamentos de la empresa, sino que trabajarían como una célula de dirección donde cada uno de ellos sería una especie de product owner de otras células con propósitos más concretos. De esa forma se iría transmitiendo el alineamiento de los propósitos, aunque cada miembro trabajase en equipo dentro de su célula, encargándose, pero no responsabilizándose de una función específica.

Por tanto, la transmisión de la visión global y las funciones se van delegando a otras células de corporate angels y se van supervisando mediante artefactos (flechas grises) y ceremonias (flechas azules)

Usamos el término product owner de scrum como ejemplo, quizás no excesivamente preciso, para expresar que estos individuos transmiten el qué desde la célula en la que participan a la célula que lo desarrollará. Lo harán con artefactos adecuados y efectuarán el seguimiento con ceremonias apropiadas en cada caso.

13.5 Relación entre Células de Agile Coaches

Del mismo modo pasa algo parecido con la estructura de agile coaches, donde las células del nivel inferior se alinean en cuanto a la agilidad con una célula de nivel superior.

Las células de agile coaches tienen además acceso a las de corporate angels para la transmisión de la visión global como cualquier otra célula, aunque esta no sea de producto (flechas azules)

13.6 Célula de Corporate Angels

Sobre los individuos:

• Entienden el modelo de Agile Corporation

• Tienen visión estratégica sobre la empresa

• Entienden que equivocarse puede estar bien, pero hay que hacerlo pronto y barato

Sobre su crecimiento:

• La situación de partida puede ser la dedicación parcial de una persona muy cercana a la Propiedad

• Adoptan especializaciones según línea de negocio y/o gobierno de áreas de expertise

• Se dividen para alcanzar más capilaridad

• Crecimiento propuesto por la propia célula según carga de trabajo, pero decidido por la célula del Agile Board que gestiona sus recursos

13.7 Célula de Agile Coaches

Sobre los individuos:

• Conocen muy bien el modelo de Agile Corporation

• Senior en gestión de empresas

• Senior en gestión de proyectos

• Senior en marcos de trabajo Agile

• Experiencia en gestión del cambio en empresas que defienden una rentabilidad

Sobre su crecimiento:

• La situación de partida puede ser la dedicación parcial de una persona subcontratada/externalizada

• Crecimiento propuesto por la propia célula según carga de trabajo

• Crecimiento decidido por la célula del Agile Board que gestiona sus recursos

13.8 Coexistencia con la Empresa Jerárquica

Es imprescindible arrancar la AEZ con una representación del Agile Board y sus funciones. Bastaría un único individuo que porte el rôle de corporate angel y un Agile coach. El primero deberá tener el apoyo de la dirección. Tendrá delegadas las funciones de la propiedad y por tanto necesitará cierto empoderamiento.

Este individuo, que podrá convertirse en célula cuando la AEZ crezca, reportará a la dirección de la empresa jerárquica. Su relación con el resto de la AEZ será una relación en agilidad, mediante interdependencias bien definidas y salvaguardando en lo posible la agilidad de las células y equipos.

El Agile coach sin embargo podrá ser un consultor subcontratado. También podrá constituirse en célula conforme se incremente su volumen de trabajo. No reportará a nadie, sino que se someterá a las interdependencias con el corporate angel definidas según lo expuesto en este documento.

Como hemos expresado, la agilidad no es un estado binario. Un sistema adaptativo complejo permite modular la agilidad global, e incluso combinar áreas con distinto grado de agilidad. El objetivo es ir desplazando hacia fuera de la AEZ las relaciones de ordeno y mando que interfieran en el autogobierno de los equipos y que irremediablemente destruyan la agilidad, reemplazándolas por interdependencias con células de gobierno. La ausencia de responsables máximos no implica la ausencia de gobierno y de caos, como ha quedado claro en lo expuesto hasta el momento.

14 Sobre cómo implantar el modelo

14.1 La Digitalización nos Presenta un Problema Complejo

Siempre buscamos soluciones simples, pero el mundo es complejo, y cualquier empresa, sea del tamaño que sea, también es un sistema complejo en sí misma. Especialmente complejo es el problema de la digitalización en el que se ve envuelta nuestra organización. Una estrategia posible es crear un proyecto con estructuras jerárquicas (o matriciales, o multidimensionales), un plan de transformación digital detallado y controles rígidos para evitar desviaciones sobre los objetivos marcados, pero no podemos estar plenamente seguros del funcionamiento de la solución propuesta. Como hemos visto en los capítulos anteriores, con esta estrategia no vamos a ser capaces de acertar en la adaptación al medio. En realidad, debemos buscar una solución parcial y probarla, corregirla y mejorarla como dicta el proceso empírico sobre el que se fundamenta la Filosofía Agile.

Para ello, debemos dotar al sistema de la agilidad suficiente para que sus partes se autogestionen en búsqueda de la adaptación a un medio cambiante, para que aprovechen las oportunidades de la digitalización de la forma que mejor encaje con su situación específica. Este sistema, además de tener agilidad, será robusto ya que su capacidad de adaptación permitirá asumir fracasos o problemas a nivel parcial.

Sin embargo, la transición de una empresa jerárquica a una empresa ágil es en sí un problema complejo que lleva tiempo. La solución no es agilizarse y entonces esperar que cada área cumpla su parte. No nos queda más remedio que arrancar los planes de transformación digital, pero debemos hacerlo de forma que sea compatible con la adopción del Marco de Trabajo de Agile Corporation, o ACF.

14.2 La Transformación Digital no es una Solución Simple

La empresa eficiente puede que tenga que abordar dos retos al mismo tiempo: la transformación digital y la agilización de su organización. Sin la segunda, la primera tendrá tan sólo validez temporal.

Como comentábamos en el apartado anterior, la digitalización no espera y necesitamos arrancar los planes de transformación digital. Lo haremos dotando a los equipos encargados del plan de la mayor agilidad posible y asumiendo que no serán del todo certeros, pero que al menos nos irán acercando a un estado viable. Cuando decimos que los dotaremos de agilidad, nos referimos a dotarlos de las necesidades esenciales para la misma, esto es, funcionar como equipo, con libertad para elegir su propósito, con la autonomía suficiente y dotándolo de las maestrías requeridas. Nuestro gobierno del proyecto será torpe, quizás más conservador de lo debido, y los equipos elegidos no serán perfectos, como tampoco lo serán las primeras versiones de las soluciones propuestas, no obstante, este será el primer paso para conseguir alinear nuestro propósito corporativo de transformarnos digitalmente mientras agilizamos nuestras estructuras.

Al mismo tiempo arrancaremos la agilización de la organización adoptando el modelo ACF. Cualquier grado de agilidad ganado en nuestra organización, incrementará las probabilidades de éxito de los planes de transformación lanzados.

14.3 Introducción a cómo implantar el Modelo

Resumiendo lo anterior, hemos justificado que la empresa se enfrenta a su adaptación al medio cambiante y que la única forma de resolver esta cuestión es convirtiéndose en un sistema complejo adaptativo donde cada parte de la organización se encargue de resolver una parte del problema. Agile es un buen marco de trabajo para resolver problemas complejos, en los que la solución no es repetible y sólo se comprende su funcionamiento una vez demostrado empíricamente. En cualquier caso, hemos de enfatizar que no hay un modelo estándar válido, sino que hablamos de un framework para construir el modelo adecuado a casa caso.

Pero el hecho de transitar desde una organización rígida y jerárquica a una Agile Corporation es en sí mismo un problema complejo a resolver, más aún si nos encontramos con planes de transformación en marcha. La solución a cómo gestionar este entorno tan complejo también nos la da el modelo Agile.

14.4 Cómo es una Agile Corporation

14.5 Estrategia

14.6 Entendimiento del reto

Sobre la propiedad:

• Está decidida a explorar la posibilidad de implantar metodologías Agile para transformar su empresa ganando agilidad en la innovación, la toma de decisiones y la implantación de dichas decisiones, todo ello centrándonos verdaderamente en el cliente.

• Entiende que Agile va más allá de su aplicación en los departamentos de desarrollo de SW y trasciende el área de Tecnología.

• Entiende que Agile conlleva un cambio cultural, que sólo es posible con un cambio del sistema.

Características del Proceso:

• No es una solución de big bang, sino que parte de una situación de partida con ámbito controlado.

• Es un proceso de mejora continua, donde la agilidad en la empresa irá mejorando por etapas.

• Es compatible y puede ocurrir al mismo tiempo que los procesos ya lanzados de aplicación de metodologías Agile en departamentos de desarrollo de producto.

14.7 Catalizadores del Sistema

Podríamos pensar que, con células de la naturaleza adecuada, las interdependencias correctas y las mecánicas oportunas, el sistema evolucionaría con el tiempo hacia el To Be que hayamos diseñado. Pero hay dos problemas con esto:

1. Por su naturaleza, si el sistema es complejo, los efectos de su composición no son pronosticables. Es decir, comprenderemos el por qué ha evolucionado el sistema de cierta manera sólo después de que lo haya hecho.

2. Deberemos tener presente la Phase Transition, una particularidad de los sistemas complejos adaptativos en acelerar la transformación de forma exponencial a partir de un punto dado. Esto supone una oportunidad para diseñar un sistema que favorezca la rápida adopción de agilidad por toda la corporación, pero este efecto también representa una amenaza. Podría producirse de forma no esperada y con el efecto no deseado. Por tanto, el proceso de transformación debe realizarse en un entorno controlado y de riesgo limitado.

Necesitamos tanto agentes del cambio como mecanismos que catalicen la transición de una forma controlada. En cuanto a los primeros, nos referimos a los corporate angels, a los Agile Coaches y a los maestros. En el segundo grupo consideraremos las paved roads, o carreteras asfaltadas, y la RTM, o Risk Threshold Management. Además, la propia AEZ servirá como catalizador del cambio de forma controlada.

Además, debemos contar con la propiedad de la Estabilidad u homeostasis, que es una propiedad de los sistemas complejos. Nos referimos a que, si tenemos un sistema complejo, aunque lo alteremos tenderá a seguir haciendo lo mismo. La alteración tiene que ser la suficiente como para que se rompan ciertas interdependencias, el sistema se libere de ataduras, e intente encontrar un nuevo estado de estabilidad.

14.8 Cómo Empezar con el Corporate Angel

El primer corporate angel podría ser el Agile Champion si éste estuviera relativamente cerca de la Propiedad (o la Alta Dirección).

Creemos que es muy recomendable que, desde los primeros días, este órgano funcione como célula. Es decir, el primer angel debería constituir un grupo de trabajo de 3 o 4 miembros cercanos a la Dirección que estén comprometidos con la agilización. No requieren en un principio conocer en detalle los principios Agile, pero sí deben tener la predisposición a escuchar al Agile Coach. Tampoco requieren dedicar un gran porcentaje de su tiempo, pero sí deben comprometerse a dos cosas:

1. Establecer la estrategia inicial.

2. Cumplir escrupulosamente con las ceremonias que se establezcan para el seguimiento.

Esta pequeña célula funcionaría, junto al coach, como una célula de ideación sobre la agilidad en la empresa. Sólo se considerará como Golden Cell cuando la Propiedad participe en ella.

No tiene como función establecer estrategia de producto, pero podría ser interesante incorporar a individuos que vayan a liderar las células de ideación de los productos más críticos con objeto de que, en su posterior segregación, estas células de producto nazcan perfectamente alineadas.

14.9 Cómo Empezar con el Agile Coach

El Agile Coach, entendido como un coach que comprende la gestión de sistemas complejos y los mecanismos de la Agile Corporation, tendrá que ser formado o subcontratado con tal propósito. La pertenencia a la empresa es siempre un plus importante por lo que, si podemos dedicar una persona al 100%, lo ideal sería formar a alguien interno y dotarle de soporte exterior a la hora de resolver problemas concretos. Aparte de ser la opción más económica, aseguraremos que también estará influenciado por los propios patrones que vamos a establecer en la AEZ.

La necesidad de incrementar o no el número de coaches dependerá de cada caso. Un coach puede dar soporte a una gran AEZ si todo va sobre ruedas. Por el contrario, requeriremos pronto una célula de varios individuos si hay patrones contrarios establecidos y muy aposentados en el sistema actual.

Debemos trabajar desde el inicio en determinar la naturaleza de las células, sus interdependencias entre coaches, angels y equipos de producto, así como entre angel y equipos de producto. Una vez establecidas las mecánicas de inicio podríamos decir que tenemos nuestra primera AEZ. Veremos a continuación algunos detalles y ejemplos sobre este ejercicio.

14.10 Planteamiento sobre los Patrones a Crear

En nuestra empresa, nuestro sistema complejo adaptativo, queremos aplicar las teorías de los sistemas complejos para determinar las bases necesarias (los componentes o elementos) para que el sistema resultante emerja de la forma deseada.

Por tanto, debemos empezar determinando los patrones deseados. Parte de estos patrones serán relativos a:

• La propia agilidad del sistema

• Crear valor para el accionista

• Crear valor para el cliente

• La propia identidad de la empresa

Estos patrones están también relacionados entre sí. No podemos establecer demasiados patrones, ya que para fomentarlos deberemos acotar la agilidad del sistema. En las secciones siguientes mostramos unos ejemplos, si bien en un caso práctico deberíamos bajarlos más a la tierra. Por ejemplo, no diríamos “fomentar maestrías”, sino que especificaríamos las maestrías concretas que creemos son fundamentales en la corporación o en un área determinada.

Para cambiar un sistema no debemos alterar a los equipos para que dejen de comportarse como lo hacen ahora, sino que debemos cambiar las condiciones del entorno para que se sientan “incómodos” con sus comportamientos actuales y vayan cambiándolos para adaptarse al nuevo entorno (las mecánicas). Kaizen (gradual improvement) puede no ser apropiado cuando queremos efectuar grandes cambios. De hecho, una empresa obsesionada con Kaizen ganará eficiencia, pero no adaptabilidad al medio (a no ser que lo que exija el medio sea reducción de costes). Es necesario aplicar Kaikaku (radical improvement) en determinados momentos.

No olvidemos además la propiedad de Estabilidad u homeostasis. Las mecánicas deberán ser suficientemente potentes como para provocar el cambio en el sistema.

14.11 Ejemplos de Patrones

NOTA: Ejemplo ilustrativo, no válido en su conjunto.

Valor para el cliente:

• Empatía con cliente final

• Alta frecuencia en entregas

• Fomentar la participación del cliente en sesiones de ideación

Valor para el accionista:

• Eficacia en paved roads

• Eficiencia en paved roads

• Predisposición al uso de las paved roads

• Cumplimiento de umbrales de riesgo determinados

Sobre agilidad del sistema:

• Relación de líder servil y no de autoridad entre responsables de áreas y equipos de trabajo a su cargo

• Gestión de productos mediante células Agile de ideación

• Uso de Scrum para desarrollo de productos

• Proliferación de maestros

Identidad de la empresa:

• Imagen de seriedad y rigor

• Cooperación con el cliente

• Compromiso con el medio ambiente

• Divertida

14.12 Cómo Empezar con las Células

Una vez establecidos los patrones objetivo, su emergencia va a depender de:

• La condición de las células y su naturaleza

• Las interdependencias entre ellas, que condicionan el funcionamiento de una respecto de las relacionadas

• Las mecánicas añadidas, que las estimulan hacia los patrones deseados

Debemos garantizar en las células la agilidad (autonomía, multidisciplina y propósito compartido) y el talento.

Ambas condiciones deberían aplicarse no sólo en la AEZ, sino en cualquier célula Agile que tengamos en la empresa (siempre que sea posible).

Para asegurarlo deberemos crear tanto la figura de Agile coach como la de corporate angel. La primera dará soporte sobre el carácter Agile de los equipos. La segunda asegurará el empoderamiento contra las fuerzas opuestas que vengan del resto de la corporación. Además, tendremos que establecer las interdependencias entre estos roles y las células Agile que queremos defender.

En cuanto al Marco de Trabajo Agile a elegir, podemos seleccionar uno en particular, como Scrum, o dejar a cada célula que adopte el que crea más adecuado para su labor (lo cual significa un grado de agilidad superior).

Una posible buena práctica para agitar el sistema en búsqueda de mejor predisposición al cambio es mezclar equipos, aunque sea de forma un poco forzada.

14.13 Cómo Implantar las Interdependencias

NOTA: Ejemplo ilustrativo, no válido en su conjunto.

La célula de ideación formada por angels y el coach deberán analizar los cuatro grupos de interdependencias expuestos en este libro.

A partir de esa labor de análisis se establecerá la estrategia de agilización, que incluirá los catalizadores adecuados: tanto la generación de nuevas células de angels especializados en un área, como maestros, paved roads, etc.

Finalmente determinarán las interdependencias básicas necesarias entre estos agentes. Conforme vayamos implantando elementos iremos resolviendo las interdependencias necesarias. Muchas además serán delegadas a los propios equipos que las diseñarán a su conveniencia y haciendo uso de su autogobierno.

14.14 Cómo Empezar con las Mecánicas

Vimos que había cuatro grupos de interdependencias según su naturaleza. De una forma parecida, tendremos las mecánicas que se corresponden con los grupos 1 y 2 de interdependencias, las que definiremos para la AEZ, y las mecánicas ya establecidas en la empresa.

Aquellas mecánicas de AEZ, como las expuestas en la sección del documento dedicado a ellas, que sean fáciles de implantar a nivel corporativo deberían establecerse como globales y así irlas extendiendo como cultura corporativa. Al mismo tiempo, deberemos proteger a la AEZ de las mecánicas ya establecidas que fomenten patrones o cultura contrarios a los deseados.

Aparte de todo esto, deberemos tener cuidado con que las mecánicas, en su conjunto, promuevan o motiven el deseo de los individuos a formar parte de la AEZ. De lo contrario serían mecánicas contrarias a la agilización.

14.15 Cómo Empezar con los Maestros

Cuando hayamos establecido la estrategia, nos serán obvias las maestrías cross necesarias en la empresa, pero esto no quiere decir que vayan a estar en todas las células, ni siquiera en todos los equipos de producto, pero sí de forma generalizada y en aquellos productos que sean críticos.

Esto derivará en un trabajo de identificar a los individuos que, al menos de forma parcial, portarán esas maestrías, así como los planes de captación requeridos. Del mismo modo diseñaremos los servicios que estos maestros requieran para su trabajo (posibles paved roads), los umbrales de riesgo cuyo cumplimiento deberán liderar, así como las interdependencias para soportar toda la estructura.

Cuando el coach comience a operar con las células de trabajo podrá identificar nuevas maestrías que resulten críticas, aunque de forma específica para dicho equipo. El mismo análisis mencionado para las anteriores se irá definiendo para éstas, aunque en ocasiones no se encuentren sinergias que impliquen paved roads o riesgos que deban controlarse fuera de los propios equipos de producto.

14.16 Barreras para Implantar las Paved Roads

Comentábamos anteriormente que la clave para acertar con las paved roads era tener un enfoque conservador a la hora de decidir si crearlas o no y, una vez creadas, preservar su autogobierno.

Si partimos de una empresa eficiente, lo normal es que tengamos ya creados servicios de obligado consumo que pretendan generar ahorros por economías de escala, ofrecer doble especialización o fomentar buenas prácticas. Estos servicios son todos potenciales paved roads a priori, aunque en el comienzo debemos poner a todos en duda.

El primer problema que nos podremos encontrar en estos servicios, por haber sido de obligado cumplimiento, es que dejen mucho que desear en cuanto a su orientación al cliente. Incluso es posible que, desde el punto de vista del cliente interno, estos servicios sean poco competitivos con respecto a los de proveedores externos.

El segundo problema será el resultante de la relación pasada entre los individuos de uno y otro equipo. Puede que encontremos complicidad entre los que proveen el servicio y los que lo consumen, por el hecho de sentirse compañeros de la misma empresa, pero también animadversión por haber estado sufriendo un servicio que, como mínimo, no satisfacía sus expectativas. Liberarles de la obligatoriedad de su consumo podría derivar en un largo periodo de rebeldía de los equipos clientes, prefiriendo consumir servicios de proveedores externos, incluso siendo éstos de peor calidad. Esta dinámica también podría corresponder con la preferencia del equipo cliente por mantener una relación cliente-proveedor con una empresa externa que satisfaga su ego con actitud servil, frente a una relación de colaboración al mismo nivel con sus compañeros.

14.17 Cómo Empezar con las Paved Roads

La estrategia a seguir dependerá de cada situación, como acabamos de ver. Una estrategia conservadora será la de articular la agilidad, al menos en el lado proveedor, antes de liberar la obligatoriedad. Empezaríamos formando las células del equipo del servicio e implantando el método de trabajo con los artefactos y las ceremonias internas básicas. Cuando el coach compruebe que estén ganando cierto hábito y destreza, pasaríamos a una segunda fase donde articularíamos además las interdependencias entre equipos cliente y los del propio servicio. Para entonces será conveniente que la agilidad de los equipos del servicio haya resultado en una mejor orientación al cliente y que el servicio ofrecido empiece a ser al menos competitivo y centrado en las necesidades de los compañeros que lo consuman. Todo ello además estará ya aderezado con mecánicas que favorezcan la colaboración.

Tanto los coaches como los angels tienen papeles importantes en este proceso. Los primeros porque podrán identificar problemas con cierta objetividad, tanto de una parte como de otra, así como colaborar en la búsqueda de soluciones. Los segundos, por su misión de alineamiento. Si un equipo de trabajo decide no utilizar una paved road en favor de un proveedor externo, deberá tener una buena explicación para ir en este caso contra las sinergias corporativas. Sin embargo, el angel no deberá forzar su uso a no ser que se esté sobrepasando un umbral de riesgo relacionado con el servicio.

Obviamente, dicho todo esto, lo ideal será empezar por aquellos servicios que presenten mayor viabilidad y probabilidades de terminar en caso de éxito.

14.18 Sobre la Identificación de Umbrales de Riesgo

Primero deberemos identificar los riesgos que son realmente importantes fuera del ámbito de los equipos.

En la Agile Corporation, con equipos autogobernados, los riesgos por debajo de un umbral en el que sólo afecten al equipo serán gestionados por el propio equipo. Sólo si superan el umbral y empiezan a afectar al resto de la compañía serán incumbencia de los corporate angels o de las áreas corporativas que los controlen.

Pero los umbrales a establecer serán distintos para cada riesgo. Por tanto, el segundo paso será especificar cuál es el umbral límite para cada uno. Será difícil no caer en el exceso de celo y establecer umbrales que no coarten la agilidad de los equipos. Determinar el umbral será fácil para algunos riesgos, cómo determinar la desviación máxima permitida en un presupuesto, o el ratio de defectos de un SW en producción. Sin embargo, en otros casos dependerán de la vulnerabilidad, las amenazas que lo componen y la naturaleza de la gestión del impacto. Es el caso del ámbito de la ciberseguridad, regulatorio o legal. Será necesario analizarlos, fijar referencias y determinar controles más complejos, si bien su implantación deberá minimizar el coste/molestia para los equipos ágiles.

También debemos tener en cuenta los riesgos asociados al incumplimiento de los patrones preestablecidos. Imponer controles al respecto implica limitar la agilidad en la corporación, pero sobrepasando ciertos umbrales podríamos desviarnos de los objetivos establecidos.

14.19 Cómo Empezar con el RTM

Lo normal en cualquier caso es que en una empresa eficiente estos riesgos ya estén siendo gestionados con controles a nivel corporativo. De hecho, lo normal es que se gestionen tanto los riesgos corporativos como los propios riesgos de los equipos con el exceso de celo ya mencionado.

Por ello, al mismo tiempo que identificamos los riesgos que teóricamente debemos gestionar a nivel corporativo, también debemos empezar por ver aquellos cuyos controles generen más molestias en los equipos ágiles, independientemente de si éstos están o no en la AEZ. Nos preguntaremos hasta qué nivel realmente impactan o no los riesgos fuera del equipo.

Por ejemplo, un riesgo de falta de calidad del servicio que se asocie por el cliente sólo a dicho servicio deberá ser gestionado por el propio equipo. Si la falta de calidad es tal que pueda generar un daño de imagen corporativa, entonces sí entrará en el ámbito de actuación de los corporate angels (o de las áreas corporativas encargadas de la gestión de dicho riesgo). La cuestión es que, a umbrales más altos, menos controles invasivos se requerirán y menos limitada estará la agilidad del equipo.

Al mismo tiempo deberemos facilitar el cumplimiento de estos umbrales con tres medidas:

1. La formación en los equipos de maestrías relacionadas con el riesgo

2. El establecimiento de interdependencias, con sus artefactos y ceremonias, para su seguimiento

3. La provisión de servicios corporativos (mejor si son paved roads) para minimizar dichos riesgos

14.20 Cómo Empezar con la AEZ

La AEZ en su comienzo es el Ecosistema Agile Zero. Es algo que se constituye pasando de tener equipos Agile deslocalizados a tenerlos en un ecosistema de agilidad gestionada.

En la AEZ seremos conscientes y gestionaremos (como un sistema complejo adaptativo) la configuración de las células, las interdependencias y las mecánicas que reinen en ella.

Además existirán al menos los siguientes elementos:

• Agile Board, con al menos un corporate angel y un Agile Coach

• El área de productos, con al menos un equipo de producto

• Un mecanismo de mejora de la agilidad a nivel corporativo, como el comité de gobierno de la agilidad expuesto anteriormente

• Un primer análisis de los patrones deseados, los patrones existentes y las deviaciones entre ellos, así como una estrategia inicial de mejora de la agilidad.

14.21 Como Ir de la AEZero a la AEZone

A partir de la creación de la AEZ como Ecosistema Agile Zero, el comité de gobierno de la agilidad irá incorporando nuevos productos. Lo podrá hacer de forma íntegra verticalmente (desde la ideación hasta la operación) o por partes. Los nuevos equipos que entren en la zona podrán hacerlo sin ser 100% Agile o perfectos, pero se someterán desde el primer día a las interdependencias con los coaches y los angels. A partir de entonces AEZ pasará a referirse como la Zona del Ecosistema Agile, porque irá creciendo y mejorando de forma continua.

Si decidimos acelerar y añadir muchos equipos que aún no sean Agile, necesitaremos la estructura adecuada en tamaño y formación de coaches y angels. De lo contrario generaremos demasiada entropía. Por otra parte, la AEZ va a ser frágil en su comienzo y sólo alcanzará velocidad de crucero y dejará de requerir un cuidado especial cuando haya llegado a un tamaño adecuado.

Al mismo tiempo que añadimos equipos de producto, podemos ir creando/añadiendo paved roads y mecanismos de gestión de umbrales de riesgo. Todo ello irá generando la necesidad de un Agile Board más grande, pero ahí debemos tener cuidado. Más gestión, más interdependencias, más mecánicas, más patrones, etc., todo ello implica menor grado de agilidad, que es nuestro objetivo inicial. El propio Agile Board, especialmente la estructura de angels, deberá controlar su tamaño y evitar la sobregestión. Su misión será gobernar para favorecer el autogobierno.

Finalmente necesitaremos un modelo de mejora continua de negocio, que no de procesos, que vaya gobernando el proceso de ampliación de la AEZ. La diferencia entre mejora continua de negocio y no de procesos es que buscaremos situaciones de avance en cuanto a alineamiento y agilidad, no en cuanto a eficiencia de procesos.

15 Anexo

15.1 Diagramas de la Agile Corporation

16 DEFINICIONES Y ACRÓNIMOS

• AEZ es un acrónimo de doble significado, que conecta con la implantación gradual de Agile en una corporación. Denominamos Agile Ecosystem Zero a la primera implantación de Agile, que no es sino un ecosistema mínimo capaz de sobrevivir integrado en la organización. A medida que vaya creciendo mediante sucesivas implantaciones incrementales, cambiaremos su denominación a Agile Ecosystem Zone.

• ACF. Agile Corporation Framework. Marco de Trabajo de la Corporación Agile.

• Backlog. Lista de elementos de mejora ordenados por prioridad y con una estimación de esfuerzo.

• Backlog de célula de trabajo. Backlog de elementos de mejora para coordinación interna de una célula o comunicación entre células.

• Backlog de producto. Backlog de elementos de mejora que corresponden a un producto o servicio, sea externo o interno.

• Backlog de mejora continua de la agilidad. Backlog de elementos de mejora decididos por el comité de gobierno de la agilidad. Independientemente de esto, todos los backlogs de células de trabajo podrán contener elementos de mejora de la agilidad de la célula.

• Células de Agile Coaches. Células enfocadas en la mejora continua.

• Células de Corporate Angels. Células enfocadas en la Función de la Propiedad.

• Células de Primer Nivel de Ideación. Son células que determinan el roadmap general del producto.

• Células de Segundo Nivel de Ideación. Son células que determinan el roadmap del producto a partir de los elementos de mejora que una célula de primer nivel establece en el backlog de producto.

• Design Thinking. Pensamiento de Diseño. Metodología de filosofía Agile que involucra a los diseñadores desde el primer eslabón de la cadena, desde la pura concepción del producto, en vez de involucrarlos al final de la misma, para hacer apetecible el consumo de un producto cuando éste ya está totalmente desarrollado.

• DevOps. Metodología de filosofía Agile que combina y gestiona como un todo las actividades correspondientes a Desarrollo y Operaciones.

• Elemento de mejora. Tarea o mejora a realizar, añadida a un backlog con un orden de prioridad y una estimación de esfuerzo.

• Kanban. Metodología de filosofía Agile basada en tableros de tarjetas.

• Lean Manufacturing. Proceso de fabricación que se centra radicalmente en el núcleo duro de la actividad fabril, eliminando todos los procesos superfluos o accesorios.

• Líder Servil es aquel cuyo liderazgo no está mando en plaza, sino que está basado en el servicio e influencia que el líder tiene en el grupo. Es un líder reconocido y respetado, no un líder designado.

• Ludificación o Gamificación. Uso de técnicas, elementos y dinámicas propias de los juegos y el ocio en actividades no recreativas, con el fin de potenciar la motivación, así como de reforzar la conducta para solucionar un problema, mejorar la productividad, obtener un objetivo, activar el aprendizaje y evaluar a individuos concretos.

• Paved Roads, Carreteras Asfaltadas. Servicios corporativos ya optimizados, que se encapsulan y se habilitan para su consumo por parte de las células de la corporación ágil

• RTM, Risk Theshold Management. Gestión por umbrales de riesgo.

• Scrum. Metodología de filosofía Agile basada en células multidisciplinares, entregas incrementales de productos al usuario final, y adaptación fulminante del producto a los cambios de requisitos.

• UX, User eXperience. Experiencia de Usuario.

17 BIBLIOGRAFÍA

• Programa Formativo “IoT e Industria 4.0”. Francisco Artés y Félix Blanco. EOI, 2019.

• https://facilethings.com/blog/es/pillars-of-motivation

• Daniel Pink. “La sorprendente verdad sobre qué nos motiva”.

• Wikipedia.

• LeSS Works (less.works).

• www.scrum.org

• https://www.scaledagileframework.com/

• Manifiesto Agile.