En el sur de Chile, existe el dicho: “muchas manos matan la guagua” (la guagua = el bebé), que significa que si hay mucha gente interviniendo en un mismo asunto, probablemente terminan entorpeciendo en vez de mejorar la situación, o para el caso, matando la guagua. Es un dicho muy interesante que nos obliga a plantearnos la siguiente paradoja:
- El Efecto Ringelmann (cuántas más personas haya en un equipo, menos esfuerzo aportará cada una de las partes individuales) y la Ley de Carson (trabajar de forma continua y sin interrupciones es más eficiente y requiere menos tiempo que un trabajo interrumpido) deberían ser, al menos, hipótesis de corroboración vital: Un trabajo en grupo del colegio es mucho más fácil de hacer entre 3 que de 6. Hacer una coreografía de baile, debería ser más fácil de 2 que de 7, etc. Escribiendo esto no puedo evitar recordar a un amigo, que solía ser apremiado con deadlines por los Program Managers. Enfrentaba insistentemente la pregunta de si debían contratar más gente para acelerar el desarrollo y el siempre respondía muy sarcásticamente: “¿Embarazar a 9 mujeres te daria un bebé en un mes?“
- Al mismo tiempo, si esto fuera cierto, los hospitales deberían tener muchas muertes de bebés en los cambios de turno: pediatras, enfermeras, nutricionistas todos al cuidado del bebé, en suma, muchas manos tocando la guagua, ¿por que entonces es tan mínima la tasa de mortalidad, si este este es el funcionamiento de la salud en gran parte del mundo?
Obviamente todo esto es una sobresimplificación. Pero la idea de ilustrar esta paradoja, es poder desenmascarar el falso dilema: El problema no está en la cantidad de manos sino en los cerebros que las operan. “Muchas manos matan la guagua” quiere decir que muchas manos mal preparadas pueden llevar a nefastas consecuencias, pero abre la oportunidad a que, en consecuencia, muchas manos bien preparadas pueden hacer cosas increíbles que el esfuerzo individual solo podría soñar. Entonces, ¿que es eso que hace que muchas manos en el hospital sean deseables, pero muchas manos en el barrio no?, a falta de un mejor concepto le llamaremos el conocimiento tribal.
Los médicos, enfermeras, paramédicos, nutricionistas, comparten un conocimiento tribal, que viene de muchos años de medicina moderna, impartida en distintas universidades del mundo. Ese conocimiento tribal, agiliza conversaciones, diagnósticos, decisiones y permite cambiar profesionales, en tanto el que entra, también posea ese conocimiento tribal. Afortunadamente para ellos, la biología cambia a un ritmo menos vertiginoso que los negocios y el software, por tanto, ese conocimiento tribal es perdurable en el tiempo y hace que la importación y exportación de profesionales sea más fácil de lograr. Ser oftalmólogo en un hospital de Santiago, requiere la misma preparación que para ser un oftalmólogo de una clínica en Chiloé.
En el software esto es radicalmente más complejo: por lo general el conocimiento tribal de un proyecto vive dentro de uno o un par de cerebros, que usualmente son los que llevan más tiempo remando en el proyecto, y por tanto, se vuelven “el diseño” del software. Si por fortuna, beneficios o presupuesto, esa persona resulta ser muy buena abstrayendo problemas y diseñando, ten por seguro que la fricción interna será mínima, siempre tendrá un responsable y se detectará a tiempo. Si por mala fortuna, beneficios o presupuesto te toca el caso contrario, el proyecto estará condenado a la prueba y el error, a las fallas de proceso sin responsable y constantes parches que “estabilicen” su funcionamiento.
Y si diseñar bien es tan determinante, ¿por qué se hace tan poco?. Tengo dos hipótesis: la agilidad mal comprendida y el bajo costo aparente de fallar rápido.
Cuando el mundo aún no conocía la agilidad, los procesos de construcción de software tradicionales eran lentos y de escasa validación por parte del “usuario” hasta que estuvieran en sus fases finales, y, aunque esto era deseable en algunos sectores (como la aeronáutica y la banca) para otros era simplemente un freno de mano para la innovación y la competencia (como para el retail y la industria de los SaaS). ¿Qué cambia entre la aeronáutica y el retail? Que fallar en las coordenadas de vuelo no tiene las mismas consecuencias que no poder llenar un carro de compras o no poder procesar un pago. A mayor riesgo mayor resguardo, a mayor resguardo más tiempo, a más tiempo mayor el costo.
Si una organización es ágil, puede construir software de manera ágil, de lo contrario debería utilizar otra metodología. ¿Cómo puedo saber si mi empresa es ágil?
- ¿Es su negocio más propenso a responder al ambiente que lo rodea en vez de seguir un plan de largo aliento?
- ¿El tamaño y complejidad de su negocio le permite confiar más en los individuos y sus interacciones en vez de procesos y herramientas?
- ¿Su negocio le permite trabajar bajo un ambiente de colaboración en vez de uno de negociación?
Space X, y X, tienen respuestas distintas para esto. Hay industrias donde fallar rápido y económico permite experimentar, empujar fronteras, en un futuro incierto y cambiante, donde un sprint es el compromiso mínimo necesario para agregar valor de manera incremental. Otras, donde la desprolijidad no es permitida y por tanto, el proceso es muy rígido y lineal.
El problema es que la agilidad, por su propia filosofía, ignora como todos esos cambios que se agregan cada sprint, tienen que integrarse con todos los anteriores y los futuros (que aún desconocemos) como una orquesta y cambia el paradigma desde un: “tómate el tiempo para pensar en la mejor respuesta” a “falla rápido y económico para llegar a la mejor respuesta”. Puesto en simple: cambia el diseño por la heurística.
Como podrá apreciar el lector, no todos los negocios pueden ser vistos de la misma forma y las mismas organizaciones, aún no teniendo software, deben escoger su forma de operar. Muchas veces no depende ni del negocio, sino que de sus colaboradores: mentes dogmáticas producen ambientes tradicionales, mentes pragmáticas producen ambientes ágiles. Para terminar con la hipótesis de la agilidad mal comprendida, me gustaría enfatizar que el problema no es la agilidad, sino que cuando se adopta en organizaciones que no son ágiles en la forma de conducir el negocio.
Y la segunda hipótesis, menos extensa pero muy atingente, es el costo actual de fallar y experimentar. Antes del cloud computing, fallar era caro. Hoy puedes montar productos de cloud computing y experimentar en cuestión de segundos por un costo tan pequeño que puede llegar a ser marginal en la operación. Cuando el ambiente funciona así, ¿para qué diseñar 3 meses si puedo avanzar a prueba y error por 6 sprints para llegar al objetivo?. La apuesta peligrosa aquí, es confiar en que el negocio priorizará las tareas en un orden conveniente para encontrar las restricciones y complejidades del diseño, pero si esto no es así, nuevos requisitos no sólo traerán cosas por agregar, sino que también cosas por refactorizar.
Algo perdimos en el camino: perdimos el diseño. Y recuperarlo no es fácil porque su valor no es evidente en el corto plazo.