←
Más deprisa que nunca: los fundamentos científicos del agile en la era de la IA

13 · Autoorganización con reglas: la lección del open source12 min read

Teoría — Autoorganización con reglas: la lección de los comunes y del open source

«Autoorganización» es la palabra más malentendida del vocabulario ágil: unos la leen como ausencia de reglas (y fabrican caos), otros como amenaza al orden (y fabrican el Manual v1.0). La ciencia dice algo más interesante que ambos: los grupos humanos llevan siglos autogobernando recursos compartidos con éxito — y sabemos cómo lo hacen, porque una politóloga se pasó la vida documentándolo y le dieron el Nobel. Esta sección presenta esa ciencia, su demostración viva más gigantesca (el software libre), una lección inesperada sobre licencias, y la historia con moraleja de lo que le pasó al agile cuando olvidó todo esto: la crítica más dura jamás escrita contra la industria ágil, firmada por los autores del manifiesto.

1. Ostrom: la tercera vía, documentada

Durante medio siglo, la teoría económica estándar sostuvo que los recursos compartidos estaban condenados — la «tragedia de los comunes»: cada usuario racional sobreexplota lo común hasta agotarlo — y que solo había dos salidas: privatizar o regular desde el Estado. Elinor Ostrom hizo lo que casi nadie: mirar. Décadas de trabajo de campo sobre comunidades que gestionan pastos alpinos, pesquerías, bosques y regadíos — incluida la huerta de Valencia, cuyo Tribunal de las Aguas — de origen atribuido milenario — lleva siglos resolviendo conflictos de riego cada jueves a la puerta de la catedral, y que Ostrom analiza en Governing the Commons (1990) — demostraron que existe una tercera vía: comunidades que se autogobiernan con éxito durante generaciones, sin privatización ni mando externo. El Nobel de Economía de 2009 (la primera mujer en recibirlo) reconoció ese programa.

Lo decisivo para nosotros es que Ostrom no encontró magia: encontró patrones. Los comunes longevos comparten ocho principios de diseño:

  1. Límites claros: quién es miembro y qué recurso se gobierna está definido.
  2. Congruencia entre las reglas y las condiciones locales (las reglas de la acequia de arriba no sirven tal cual para la de abajo).
  3. Elección colectiva: quienes cumplen las reglas participan en modificarlas.
  4. Monitoreo realizado por los propios usuarios o por gente que les rinde cuentas — no por inspectores ajenos.
  5. Sanciones graduadas: la primera infracción recibe una conversación, no una ejecución; la reincidencia escala.
  6. Resolución de conflictos rápida, barata y accesible (el Tribunal de las Aguas: oral, semanal, gratuito).
  7. Reconocimiento del derecho a organizarse: la autoridad externa no pisotea las reglas propias.
  8. Anidamiento policéntrico (en sistemas grandes): capas de gobierno encajadas, cada una con su ámbito.

Y esto no quedó en observación: el meta-análisis de Cox, Arnold y Villamayor-Tomás (2010, Ecology and Society, un centenar de estudios) confirmó que los casos de éxito se asocian con la presencia de los principios y los fracasos con su ausencia. La propia Ostrom, en su Nobel lecture, comentó con su franqueza característica que quizá debió llamarlos «best practices» — no son un plano rígido sino regularidades de lo que sobrevive.

Ahora traduce al vocabulario de este curso, porque la correspondencia es casi vergonzosa: un equipo con membresía estable y ámbito claro (límites — Hackman, sección 5), working agreements escritos por quienes los cumplen y revisados en retro (elección colectiva + congruencia local), trabajo visible en tableros públicos (monitoreo entre pares, no vigilancia externa — la identificabilidad sana de Karau y Williams), conversación antes que expediente (sanciones graduadas — la cultura justa de la sección 10), facilitación accesible para conflictos (principio 6), y una dirección que reconoce la autoridad del equipo sobre su proceso (principio 7 — el que la «transformación» impuesta viola siempre primero). La autoorganización que funciona no es ausencia de reglas: es soberanía sobre las propias reglas, con estructura. Trist lo vio en las minas en 1951; Ostrom explicó por qué es estable.

2. El open source: el mayor experimento de comunes de la historia

Si los principios de Ostrom parecen abstractos, tienes su demostración corriendo en el ordenador desde el que lees esto. El software libre es un común de conocimiento — el análisis canónico es de Yochai Benkler ("Coase's Penguin, or, Linux and the Nature of the Firm", Yale Law Journal, 2002, en abierto): la producción entre pares basada en el procomún como tercer modo de producción junto al mercado y la empresa — y sus comunidades longevas son manuales de gobernanza aplicada:

  • The Apache Way (Apache Software Foundation): autoridad ganada — «la influencia se basa en mérito ganado públicamente», individual e intransferible: nadie manda por su cargo en otra empresa —; comunidad de pares (participan personas, no corporaciones); comunicación abierta (toda decisión en listas públicas y archivadas: el monitoreo de Ostrom); consenso; y el lema que ordena prioridades: «Community Over Code» — una comunidad sana importa más que el buen código, porque la comunidad sana produce código bueno y el código bueno sin comunidad muere.
  • Debian: una constitución formal (versión vigente 1.9), un líder electo anualmente, un comité técnico, y decisiones mayores por resolución general con voto Condorcet — más un Contrato Social público. Gobernanza explícita, versionada y enmendable: el principio 3 de Ostrom con control de cambios.
  • La IETF, que gobierna los estándares de Internet, con el credo formulado por David Clark en 1992 y canonizado en el RFC 7282:

"We reject: kings, presidents and voting. We believe in: rough consensus and running code." [traducción propia] «Rechazamos reyes, presidentes y votaciones. Creemos en el consenso aproximado y el código que funciona.»

El rough consensus merece estudio propio porque resuelve el dilema del Manual v1.0: no es unanimidad (que da veto a cualquiera) ni votación (que permite ignorar a la minoría técnicamente correcta): es el estado en que todas las objeciones técnicas han sido abordadas — respondidas con argumentos, no necesariamente aceptadas — y ninguna queda sin tratar. Combinado con «running code» — la evidencia funcionando pesa más que la opinión —, es un mecanismo de decisión que cualquier equipo puede adoptar mañana.

  • Y el texto fundacional de la cultura: Eric Raymond, The Cathedral and the Bazaar (1997-2000, íntegro en catb.org bajo Open Publication License): el desarrollo «bazar» — abierto, temprano, masivamente revisado — contra la «catedral» cerrada. Sus lecciones más citadas: "Release early. Release often. And listen to your customers" — que el agile industrializó como entrega frecuente — y la Ley de Linus: "Given enough eyeballs, all bugs are shallow" («con suficientes ojos, todos los bugs son superficiales») — el argumento fundacional de la revisión por pares masiva. Honestidad de rigor: CatB es un ensayo de practicante, brillante y no experimental; la investigación académica posterior sobre open source matiza sus afirmaciones (los ojos tienen que mirar de verdad: bugs célebres vivieron años en código abierto ante miles de ojos que no miraban). Y el movimiento InnerSource (InnerSource Commons, materiales CC BY-SA) es la reimportación de todo esto a las empresas: repositorios internos abiertos, contribución entre equipos con revisión del equipo dueño, decisiones documentadas en público — Conway hackeado por gobernanza.

3. Las licencias como lección de gobernanza

Hay una dimensión de esta historia que parece jurídica y es profundamente organizativa: bajo qué términos se comparte el conocimiento sobre cómo trabajar. El contraste es elocuente:

  • El Manifiesto Ágil se publicó con una condición peculiar: puede copiarse libremente, pero solo íntegro y con su aviso — sus autores intuyeron que el mayor riesgo del texto era el troceo conveniente. (Acertaron: media industria cita «responder al cambio» y omite «hay valor en los elementos de la derecha».)
  • La Scrum Guide es CC BY-SA — cualquiera puede leerla, traducirla y adaptarla compartiendo igual. Y su evolución documenta una lección: la versión 2020, respecto a la de 2017, recortó prescripción — fuera las tres preguntas obligatorias de la daily, fuera los subequipos; «un marco mínimamente suficiente», autogestión en lugar de autoorganización dirigida, menos de trece páginas. Los propios autores llevaban años viendo su marco convertirse en liturgia y respondieron quitando liturgia — la dirección exactamente opuesta a la del Scrum industrializado.
  • La Kanban Guide es Creative Commons; Sociocracia 3.0 (patrones de gobernanza por consentimiento) es CC BY-SA; la Open Practice Library es CC BY; el Cuaderno de Lantana — y ya el de Aurelia — siguen esa estirpe.
  • Y SAFe, el framework de escalado dominante en la gran empresa, es propietario: su contenido requiere permiso escrito para reproducirse, y su ecosistema — certificaciones por niveles, renovaciones anuales, consultorías acreditadas — es un modelo de negocio construido sobre la complejidad del propio marco.

La correlación no es casual, y es la lección: el conocimiento organizativo publicado en abierto puede ser examinado, criticado, adaptado y mejorado por quienes lo usan — es decir, puede gobernarse como un común (principio 3 de Ostrom); el conocimiento propietario solo puede comprarse y cumplirse. Nótese que esto no es un argumento de precio sino de epistemología: un marco que no puedes adaptar legalmente tampoco puede aprender de ti. Sobre SAFe conviene la honestidad que este curso practica: responde a un problema real (coordinar decenas de equipos, cumplimiento normativo, presupuestos anuales — la muralla de la sección 11) y su éxito comercial señala una demanda genuina; la crítica seria no es «es malo», sino que reintroduce planificación en cascada por capas bajo vocabulario ágil, que su incentivo económico apunta a la complejidad (cada rol nuevo es un curso nuevo), y que contradice frontalmente la autogestión de la Scrum Guide 2020 — Ken Schwaber lo formuló como cisma filosófico: Scrum controla el riesgo mediante empirismo; SAFe intenta controlarlo mediante predictibilidad.

4. El «agile industrial complex»: la crítica desde dentro

Y así llegamos a la historia con moraleja, que Bruno vivió y las citas documentan. Lo que le ocurrió al agile tras 2001 es el caso de estudio perfecto de un común que pierde su gobernanza: el vocabulario se privatizó de facto (certificaciones, marcas registradas, frameworks propietarios), las prácticas se separaron de sus porqués, y la imposición sustituyó a la adopción. No lo dicen los enemigos del agile; lo dicen sus fundadores, por escrito y en abierto:

  • Martin Fowler, charla "The State of Agile Software in 2018" (transcripción en su web): "The Agile Industrial Complex imposing methods on people is an absolute travesty" — «que el Complejo Industrial Ágil imponga métodos a la gente es una absoluta parodia» [traducción propia]. Sus tres retos para recuperar el rumbo: expulsar la imposición (el equipo decide cómo trabaja), recuperar la excelencia técnica (la mitad olvidada: tests, refactoring, integración continua), y organizarse en torno a productos, no proyectos.
  • Dave Thomas, firmante, "Agile Is Dead (Long Live Agility)" (2014): "The word 'agile' has been subverted to the point where it is effectively meaningless" — la palabra, subvertida hasta la insignificancia. Su contrapropuesta cabe en cuatro pasos que son el bucle de este curso entero: averigua dónde estás; da un paso pequeño hacia tu objetivo; ajusta tu comprensión con lo aprendido; repite. Y ante alternativas parecidas, «elige la que haga más fácil el cambio futuro».
  • Andy Hunt, firmante, "The Failure of Agile" (2015): la palabra «se ha convertido en eslogan: insignificante en el mejor de los casos, patriotera en el peor» — y el diagnóstico de fondo: los practicantes siguen reglas concretas sin comprender los principios, y «las prácticas canónicas de los métodos populares llevan más de una década esencialmente sin cambios» — un método sobre la adaptación, fosilizado.
  • Ron Jeffries, cocreador de XP, "Developers Should Abandon Agile" (2018): distingue el agile de los valores del «Dark Agile» y «Faux Agile» corporativos — cuyo efecto sobre los equipos describe como «más interferencia con los desarrolladores, menos tiempo para trabajar, más presión y exigencias de "ir más rápido"» — y recomienda a los desarrolladores desligarse de cualquier método con marca y volver a los valores, los principios y la excelencia técnica.

La lectura superficial de estas citas es «el agile fracasó». La lectura correcta, con las gafas de Ostrom, es otra: fracasó la versión del agile que violó los principios del común — reglas impuestas por externos (violación del principio 3 y 7), monitoreo por auditores ajenos (violación del 4), congruencia local sustituida por talla única (violación del 2), y un incentivo económico — el complejo industrial — alineado con la complejidad y no con los usuarios. El agile que este curso ha ido reconstruyendo desde la ciencia — el de los equipos soberanos sobre su proceso, las reglas con porqué, la mejora con datos — no solo sigue vivo: es el único que alguna vez funcionó. La respuesta de Aurelia al Manual v1.0 — defaults con porqué, bifurcación documentada, mínimos justificados y enmendables, transparencia en lugar de auditoría — no es una ocurrencia simpática: es la aplicación de todo lo que este capítulo sabe sobre por qué unos comunes duran mil años y otros mueren en la segunda auditoría.

Para llevar

  • La tragedia de los comunes tiene tercera vía documentada (Ostrom, Nobel 2009): comunidades autogobernadas con éxito durante generaciones, con ocho principios de diseño confirmados meta-analíticamente (Cox 2010). Los working agreements de un buen equipo son esos principios en miniatura: soberanía sobre las propias reglas, con estructura.
  • El open source es el experimento de comunes más grande de la historia y su gobernanza es copiable: autoridad ganada en público (Apache), constituciones enmendables (Debian), rough consensus and running code (IETF) — objeciones abordadas y evidencia funcionando por encima de rangos y votaciones.
  • Las licencias son gobernanza: el conocimiento abierto (Scrum Guide CC BY-SA, Kanban, S3, los cuadernos) puede ser adaptado y mejorado por sus usuarios — puede aprender —; el propietario solo puede comprarse y cumplirse. Y la Scrum Guide 2020 recortando prescripción es la seña de sus autores contra su propia industria.
  • La crítica más dura al «agile» corporativo la firmaron los fundadores: parodia (Fowler), palabra sin significado (Thomas), eslogan (Hunt), Dark Agile (Jeffries). Lo que murió fue el agile que violó los principios del común: imposición externa, auditoría ajena, talla única, incentivos alineados con la complejidad.
  • Para gobernar una forma de trabajar sin congelarla ni disolverla: mínimos pocos y justificados, defaults con su porqué, derecho a bifurcar documentando, cambio por procedimiento accesible, y transparencia entre pares en lugar de inspección. Es Ostrom, es Debian, y es lo que sobrevive.

Para profundizar