Elementos integradores de LeSS

Por mucho tiempo se ha estado buscando la combinación que mejor funcione y que permita que múltiples equipos Scrum puedan trabajar de manera productiva. Los creadores de LeSS, siguiendo un enfoque de experimentación, acabaron descubriendo que cosas no funcionan y cuales pueden tener buenas chances de funcionar.

Es precisamente porque con Scrum no hay receta cierta que muchos errores se acaban repitiendo una y otra vez. A lo anterior hay que sumarle el síndrome del “yo soy diferente” que básicamente consiste en creer que por alguna razón lo que no le funciona a nadie a mí me acabará funcionando bien.

Entrando en tema, en LeSS existen elementos que centralizan y otros que descentralizan. La idea de los centralizadores es crear alineación y seguir una linea común y desde luego los descentralizadores están para proveer autonomía y fomentar la creatividad. En este post hablaré de solamente un par de estos elementos centralizadores.

Un solo Product Owner para todos

Dentro de Scrum básico ya se veía desde hace décadas que la figura de un PO empoderado, visionario, emprendedor y que concibe el producto de manera sistemática, acaba siendo fundamental para llevar a buen termino el trabajo de varios equipos.

Desde luego lo anterior no quiere decir que el PO no escucha a nadie, por el contrario esta en constante comunicación con todos los equipos, interesados, clientes, usuarios, etc., pero al final del dia es el/ella quien tomas las decisiones de producto.

Visto desde la perspectiva opuesta, tener múltiples POs acaba creando dos grandes problemas:

  1. Una jerarquía accidental con múltiples niveles donde la comunicación fluye rápidamente de abajo hacia arriba pero no necesariamente igual de bien en la dirección contraria
  2. La demora en la toma de decisiones pues estas deben ser consensuadas en largas reuniones

Todos o nadie querrá ser ese PO

Si el salario, privilegios, poder de decision e influencia están concentrados en ese único PO, desde luego que todos en los equipos (o fuera de ellos) ambicionarán esa responsabilidad.

Es ahi donde precisamente LeSS propone hacer cambios sistémicos profundos dentro de la organización para que la figura del PO sea influyente y decisiva mas no jerárquica y burocrática.

En el extremo opuesto, ¿qué hacer cuando nadie quiere ser ese PO? La respuesta a la pregunta anterior puede ser el síntoma más no la causa raíz, quizás la verdadera razón resida en que la organización no crea productos innovadores, sigue recetas antiguas o simplemente castiga y busca responsables. 

Al explorar las causas raíz quizás se desvelen ante nosotros las verdaderas razones por las cuales nadie de buena gana se quiere aventurar a ser el PO de varios equipos.

Un unico repositorio sin ramas

La idea de que cada desarrolladores es libre, feliz y más productivo avanzando en solitario con su copia local de código es simplemente eso, una idea; idea qué por cierto ha probado una y otra vez ser contraproducente. Desde luego en este punto comenzarán Ustedes a pensar en contraargumentos como:

  • Es que así hemos trabajo siempre
  • Es que la gran empresa X a la que miramos con admiración trabaja de esta manera
  • Es que el manager de desarrollo, que hace 15 anos es manager y no desarrollador, nos dijo que trabajemos así
  • Es que en la universidad yo trabaja así y a eso estoy acostumbrado
  • Es que yo hago mi parte y luego veré como integro (si llego a integrar mi trabajo con el de los demás)
  • Y la clásica, este no es un problema para nosotros porque somos “diferentes”

Acortaré el camino y les daré la respuesta a sus males: todos los desarrolladores, en todos los equipos Scrum, todos los dias, en incrementos muy pequeños, integran su código sobre un repositorio que no tiene ramas.

Si lo anterior es difícil de entender vuelva a leerlo y verá que el problema no esta en el entendimiento de la oración sino en lo contraintuitivo que suena. Contraintuitivo porque estamos acostumbrados a hacer lo contrario de lo simple, disciplinado y ordenado.

La pesadilla de la integración

“Ya terminamos nuestras historias, solamente nos falta integrarlas”, ¿habrán escuchado de casualidad la frase anterior? De haberla escuchado quizás se hicieron preguntas como las siguientes:

  • ¿Cuánto tiempo tomará integrar todo?
  • ¿Porque no integramos antes?
  • ¿Y después de integrar recién vamos a poder probar si todo funciona?
  • ¿Qué vamos a mostrar en el Sprint Review de los equipos si nada esta integrado?
  • Y una pregunta existencial aún más profunda, ¿porque será que los desarrolladores desarrollan su código sin integrarlo continuamente?

Facilitaré la vida de mis lectores respondiendo solo a la última pregunta, los desarrolladores no integran su código frecuentemente porque piensan que integración continua es igual a una herramienta que compila el código de todos.

En LeSS redescubrimos un viejo concepto de eXtreme Programming, integración continua es integrar continuamente al final de cada ciclo corto e integrar siempre sobre el repositorio central.

Si lo anterior llega a ser entendido, digo realmente entendido, y practicado con una disciplina espartana, finalmente habremos despertado de la pesadilla de la integración.

La despedida

Así como existen elementos de centralización organizativa, como es el caso de tener un único PO, y elementos de centralización del trabajo técnico, como es el tener un único repositorio sin ramas, existen muchos mas elementos centralizadores dentro de LeSS – elementos que espero poder describir a futuro en otro post.

Sin embargo este juego de centralizar algunas cosas y descentralizar otras requiere un cambio profundo y la motivación para mantener este cambio. Al final LeSS, como herramienta de rediseño sistémico, lo que pretende es precisamente hacer que la forma cómo las organizaciones se estructuran cambie y de esta manera impactar el trabajo mismo y consecuente la organización de múltiples equipos Scrum.

Liderazgo y gestión del conocimiento

Siglos atrás era mucho menor el conocimiento necesario para emprender una actividad comercial, generar lucro y sostener una familia. De hecho el conocimiento era tan especifico que eran prioritariamente los artesanos quienes los poseían; de aquí es que podemos inferir que los artesanos como herreros, sastres, carpinteros y otros tenían un conocimiento profundo pero no amplio.

Las empresas, que dicho sea de paso son una invención relativamente moderna, si existían giraban en torno al taller de un artesano que con sus operarios y aprendices generan bienes para la venta. En ese contexto que casi ya no existe era muy sencillo pensar que quien dominaba su oficio podia generar productos, acomodarlos en el mercado, y llevar una vida relativamente tranquila.

Saltando al tiempo presente

A diferencia de lo que pasaba dos siglos atrás, hoy la mayoría de los profesionales trabaja, trabajó o aspira a trabajar en una gran empresa. Las empresas como tales son vistas por las sociedades como unidades productoras de riqueza y que emplean y brindan oportunidades de crecimiento a sus trabajadores.

Sin embargo hoy más que antes se hace necesario pensar en que el conocimiento que se aglutina dentro de una empresa es clave, no solo para seguir operando, sino también para sobrevivir en estos tiempos de alta competitivad e incertidumbre.

La gestión de este conocimiento, que dicho sea de paso es intangible y colectivo, es algo de lo que poco se habla en los círculos de lideres. 

La quimera del plan de capacitación

Muchas empresas interpretan la adquisición y gestión del conocimiento como algo que puede ser planificado, medido y gestionado por un departamento especifico. Lo anterior generalmente deriva en una lista de cursos, certificaciones y horas de entrenamiento que los empleados de una empresa deben completar si quieren crecer o mantener sus empleos.

Sin embargo hay varios factores que juegan en contra de este enfoque, por citar algunos:

  • El aprendizaje más efectivo ocurre en grupo y no de manera individual
  • Aprender requiere fuerzas intrínsecas no cuantificables como motivación y compromiso
  • El aprendizaje no tiene principio y fin mas es una actividad recurrente y atemporal
  • Los adultos necesitamos aprender de manera divertida

Si los puntos anteriores resuenan en la mente del lector entonces quizás comienza a formarse la idea de que si es tan difícil lidiar con el aprendizaje porque mejor no hacer terciarización de tareas, proyectos y conocimiento.

Terciarizar o no terciarizar, esa es la pregunta

La terciarizacion se vuelve algo tentador pues es fácil pensar que si no tengo el conocimiento dentro de una empresa puedo comprarlo afuera a un precio razonable. Seamos sinceros, quiero terciarizar para pagar lo menos posible y obtener un servicio, producto o conocimiento de altísima calidad.

La terciarización de actividades mecánicas, distractivas pero necesarias, como digamos la limpieza de oficinas, tiene total sentido. Al final como lideres de una empresa no necesitamos que nuestros empleados se vuelvan expertos en limpieza si nuestro rubro es otro. Sin embargo hay tareas y conocimiento que son el centro mismos del negocio que no pueden ni deben ser terciarizados.

Conocimiento y software

El software, y lamento comunicar esta noticia, no es un activo fijo, no es barato, no es simple de hacer, no es estático y no debe de ninguna manera ser de baja calidad.

Un paréntesis, creo que es económico pensar como líder de una empresa que puedo tener ciertos componentes de la infraestructura y operaciones de una empresa que no necesariamente deben ser de primerísima calidad, por ejemplo papel, escritorios, sillas, etc. Sin embargo es muy riesgo trabajar con software de dudosa o baja calidad.

Retomando paso una idea poderosa: el software es la expresión del conocimiento de una empresa. Explicando un poco mejor la idea anterior presento un ejemplo, si tenemos un gran banco con operaciones transnacionales el “como” ese banco sirve a sus clientes esta reflejado en reglas de negocio, formulas, cálculos, excepciones, etc. que viven no en papel sino en software. 

Una otra idea poderosa, el software cambia pues el negocio también cambia. Entonces si el software cambiará constantemente, será el conocimiento el que permitió crear software diseñado para cambiar, es decir software que abarata el costo del cambio. En este punto dirán Ustedes, ¿pero y cuál es el problema si tengo un terciarizador que me hizo el software y lo puede cambiar?

Mi respuesta a la pregunta anterior es doble: primero, acaban de diseñar su empresa para ser constantemente dependiente de alguien (léase relación potencialmente asimétrica), y segundo, el conocimiento no existe mas dentro de las competencias directamente bajo su control (lease refuerzo de la relación asimétrica con el terciarizador).

Bueno, bonito, barato y leal 

En un mundo ideal podríamos pensar que existen proveedores de servicios terciarizados que son excelentes en lo que hacen, y posiblemente los hay en muchos rubros más no en el software. Mi afirmación anterior posiblemente hiere la sensibilidad de los lectores más no es mi interior criticar sino enfatizar que el software para ser considerado “bueno” debe tener un costo de cambio minino (Adaptabilidad = Agilidad, ¿recuerdan?)

El software puede también ser “bonito” cuando reúne un grupo de atributos que hacen que quienes lo utilizan piensan de él como una pieza fina de arte. Más ser “bonito” no implica para nada dejar de lado el pragmatismo de que el software se hizo para resolver algún problema y necesidad y es en sí una herramienta para la generación de ganancias.

Barato, oh barato, ¿cuántas veces compraran barato y acabaron pagando caro? Yendo más atrás con esta pregunta, para que algo (un servicio, un conocimiento o software) se vuelva mucho más barato tendría que realizarse en un país cuya economía y costo de vida son correspondientemente mas baratos. Jugando al economista, que por cierto no lo soy, lanzo la siguiente hipótesis, un país cuya economía es más barata también produce un sistema educativo de menor calidad que consecuentemente repercute en la capacidad de sus profesionales de adquirir y dominar conocimiento avanzado. Jugando al sociólogo, que tampoco lo soy, lanzo una segunda hipótesis, un país con una economía limitada acaba produciendo hábitos de comportamiento en sus profesionales que no necesariamente les permitirán ser disciplinados, colaborativos y creativos.

Si por fortuna encontraron un proveedor bueno, bonito y barato, ahora surge el tema de la lealtad pues los competidores de Ustedes también querrán trabajar con ese proveedor. Desde luego Ustedes dirán “pero tenemos firmado un contrato de exclusividad”, y mi contra respuesta es que si bien ese contrato existe ese proveedor opera en un país donde el ámbito legal no es necesariamente transparente. Jugando al abogado, que por cierto tampoco lo soy, lanzo una tercera hipótesis, un contrato no puede limitar por completo el accionar de un proveedor en un país a miles de kilómetros y cuyo sistema legal puede no operar de manera correcta todo el tiempo.

Lideres generalistas

Mis argumentos anteriores tratan de ayudar a formular esta hipótesis:

  • Los lideres de empresas deben tener un conocimiento amplio que les permita entender los diferentes aspectos de cómo se genera valor dentro de sus empresas.
    • Complementando la hipótesis anterior, no entender por completo la importancia y complejidad del software puede comprometer la generación de valor.

La hipótesis anterior tiene varias derivaciones, quizás la primera y más natural de ella es que Ustedes dirán “pero no somos una empresa de software”, y quizás no lo sean, digo si hacen todo absolutamente a mano y a la antigua. Mas si por el contrario, usan, consumen, se integran, canalizan, etc. sus operaciones cotidianas y generadoras de valor a través de software, lamento comunicarles que en realidad son una empresa de software aplicada al rubro X.

Concebirse como una empresa de software no es algo malo en lo absoluto, de hecho la Agilidad, Scrum y otros derivados vienen del software. Entender porque vienen del software les abrirá los ojos hacia una forma de management más moderna que se basa en algunos principios simples que parafraseo a continuación:

  • Organizar la empresa en torno a equipos de producto que resuelvan problemas reales y generen valor
  • Mantener el realismo a través de la cercanía constante con el mercado y los clientes
  • Habilitar la comunicación y colaboración alejándose de la burocracia

Ser un líder generalista me ayudará también a entender mejor este trabalenguas: equipos pequeños de funcionalidad cruzada formados por especialistas-generalistas, empresas lideradas por generalistas-especialistas. El trabalenguas anterior es la base de lo en el mundo Agil llamamos “equipos Scrum” y “organizaciones Agiles”.

El cierre

Escribir estas ideas no fue fácil, de hecho solo lo hice porque un amigo muy querido me pido hacerlo. Espero que algunas de estos pensamientos hayan detonado en Ustedes algún sentimiento, un acuerdo, un desacuerdo, una reflexión y por lo menos la sensación de haber invertido algo de su tiempo leyendo un punto de vista alternativo.

Un pensamiento final, como líder puedo entender “que” empresa estoy liderando y puedo tener mi propio estilo de liderazgo, y es precisamente ese “estilo” de liderazgo el que irá cambiando si voy entendiendo el “porque” que hay detrás de la Agilidad.

Reflexiones después de leer “The Age of Agile”

Stephen Denning escribió en 2018 “The Age of Agile“, libro en el cual plantea la tesis de que nuestras sociedades, después de pasar por varias innovaciones tecnológicas (e.g. canales, trenes, acero, producción, en masa, y telecomunicaciones) se encuentran en el tiempo presente en una era de gran cambio e incertidumbre, condiciones que claman por la necesidad de incorporar la Agilidad como el paradigma dominante dentro de las empresas.

Sin embargo este clamor −que más que un capricho o una corriente de modernidad, es una necesidad− se ve grandemente limitado por la visión tradicional de gestión que tiende a centralizar poder económico y de decisiones en niveles ejecutivos. En la segunda parte de su libro Denning hace un análisis muy profundo acerca del efecto −en general negativo− que ha tenido en la empresas el emitir acciones e incentivar a los ejecutivos para que siempre traten de maximizar el valor de cotización esas acciones.

Continuando con su análisis Denning nos recuerda que el ofrecer acciones a ejecutivos como parte de su compensación, o permitir que las empresas compren y revendan sus propias acciones; en general ha traído consecuencias negativas para las empresas. Desde luego las practicas anteriores han hecho millonarios a varios ejecutivos e inversionistas pero no han contribuido a crear empresas con capacidad de innovación que hagan felices a sus trabajadores y a su entorno.

Agil viene en contraposición pues apunta exactamente a lo contrario, es decir: a crear un ambiente humanizante y gratificante donde los trabajadores puedan innovar a gusto y crear de manera sostenible productos con valor para los cliente finales. Un corolario de lo anterior es que en una empresa que aspira a ser realmente Agil no se necesitan ejecutivos estrella, sino más bien trabajadores capaces y motivados que se autoorganicen en equipos pequeños que creen productos y resuelvan necesidades.

Denning hace también una revision historia para tratar de llegar a los orígenes de la Agilidad como concepto. Según él fue Helmuth von Moltke, un general prusiano que en el siglo XIX, quien introdujo la adaptabilidad y los equipos pequeños como parte de la doctrina militar que aplicaba con sus tropas. Von Moltke fue un innovador para su tiempo pues desafió la noción común de su época que planteaba que los generales mandaban y los soldados solamente obedecían.

Denning plantea casi al final de su libro que para que las empresas realmente se puedan agilizar, el cambio debe ocurrir en diferentes instancias, a saber:

  • Los gerentes deben percibir que un nuevo tipo de management es necesario y estar dispuestos de corazón a entenderlo, adoptarlo y practicarlo.
  • Las juntas directivas de las empresas deben entender que las empresas no existen solamente para incrementar el valor de las acciones, y que por el contrario existen para crear valor y ocuparse de la gente.
  • Los gerentes financieros deben dejar de pensar que enviar trabajo a países con salarios más baratos realmente ayuda a reducir costos.
  • El sector financiero debe dejar de incentivar prácticas que se enfoquen solamente en obtener lucro temporal a cualquier costo.
  • Los organismos reguladores deben sancionar comportamientos de empresas que pretenden mostrar a cualquier costo que el precio de sus acciones sube pero en desmedro de la innovación, la capacidad creativa y la motivación de sus empleados.
  • Las agencias calificadoras deben dejar de tomar el precio por acción como el indicador definitivo que separa a las empresas pseudo exitosas de las demás.
  • Los inversionistas deben dejar de pensar que al comprar acciones se convierten en dueños de una empresa y por tanto tienen derecho a extraer lucro sin importar las consecuencias a largo plazo.
  • Los politicos debe trazar políticas más coherentes que tiendan a favorecer empresas que creen ecosistemas de innovación y bienestar.
  • Las escuelas de negocio deben dejar de enseñar teorías de administración que no condicen con los tiempos actuales.
  • La prensa debe dejar de presentar como héroes a los ejecutivos que ganan millones en empresas donde los demás empleados ganan muchísimo menos.
  • Y finalmente, los lideres intelectuales deben pensar y seguir explorando hacia donde nos llevara la Agilidad en los próximos anos.

Todos los cambios de la lista anterior pueden sonar drásticos y en verdad si lo son, mas no son utópicos y por el contrario se hacen necesarios. Denning al final del libro nos dejó un pensamiento alentador de Margaret Mead quien dijo: “Nunca dudes que un pequeño grupo de ciudadanos reflexivos y comprometidos puede cambiar el mundo. De hecho, es lo único que lo ha hecho”.