El framework Honey Badger: gestionar equips híbrids humà-IA el 2026
Gairebé tots els frameworks àgils que avui es fan servir a producció es van dissenyar abans que els assistents d'IA entressin al flux de treball diari. Scrum, SAFe, Kanban, PRINCE2 — tots donen per fet que la feina la fan humans, amb les eines fora del perímetre de l'equip. En aquests frameworks, la IA hi apareix com a «tooling»; en el millor dels casos, com una capa de productivitat.
Aquest supòsit comença a fer aigües. A la majoria d'organitzacions d'enginyeria amb què treballo, l'assistent d'IA no és una eina que el desenvolupador té al costat: forma part del bucle. Agafa tiquets, redacta codi, resumeix context, executa anàlisis, escriu documentació. Tractar-lo com una eina al marge del bucle produeix una fricció mesurable: artefactes de procés que ignoren on passa la feina de debò, mètriques de rendiment que no recullen la contribució de la IA, i buits de responsabilitat quan la feina produïda per la IA falla.
El Honey Badger Management Framework (HBMF), presentat per Georgios Fradelos el 2024, pren la posició contrària: els assistents d'IA són membres formals de l'equip. Tenen rols definits, accés definit, límits definits. El framework també incorpora el compliment ESG dins del model operatiu, en lloc d'afegir-lo al final com una capa de reporting. Val la pena entendre'l, encara que no l'adoptis sencer, perquè les seves decisions de disseny revelen els forats reals de l'àgil convencional quan la IA és dins del bucle.
Què té de diferent l'HBMF
Si li traiem el nom, l'HBMF és un conjunt reduït de decisions de disseny amb molt de criteri:
Sprints de set dies, cancel·lables. Més curts que les dues setmanes per defecte de Scrum, i amb permís explícit per cancel·lar un sprint a mig camí si l'objectiu ja no justifica la feina. L'argument econòmic és la teoria d'opcions reals: els lots petits preserven l'opcionalitat; els sprints llargs la destrueixen.
Dos subequips que competeixen dins d'un mateix equip. El mateix problema, dos intents en paral·lel, jutjats pel resultat. És competició governada: una estructura de torneig dins del perímetre de l'equip, amb governança explícita per evitar-ne els modes de fallada (sabotatge, erosió de l'ajuda mútua, col·lapse de la seguretat psicològica).
Integració obligatòria de la IA. Cada equip té un assistent d'IA designat per a la feina de coneixement. L'alta direcció fa servir el mateix assistent. La IA no té autoritat de decisió — aquest punt és crític — però se la tracta com un contribuïdor: el que produeix forma part del lliurable de l'equip, no del truc de productivitat privat de ningú.
Declaracions obligatòries de llacunes de coneixement. Cada membre de l'equip declara, cada setmana, un punt fort en un camp concret i una llacuna de coneixement. Públic, visible al dashboard, sense estigma. La gràcia és fer aflorar el que la gent no sap abans que es converteixi en un defecte.
Dos rols de lideratge, no un. Un Manager respon dels requisits de producte i de les decisions de recursos. Un Guru respon del compliment del procés, de la transferència de coneixement i de la transparència del dashboard, amb dret d'escalada al nivell C. La separació és deliberada: deslligar l'autoritat de producte de l'autoritat de procés evita el conflicte d'interessos que llasta els frameworks on un sol rol fa totes dues coses.
ESG incrustat al model operatiu. L'eficiència energètica, la transparència i l'accessibilitat són restriccions de cada sprint, no reporting a nivell de portafoli. L'assistent d'IA, que fa servir tothom, forma part de l'argument ESG: abarateix el cost energètic marginal del treball cognitiu en comparació amb escalar plantilla.
Què encerta l'HBMF
Unes quantes d'aquestes decisions no són gens òbvies i val la pena mirar-se-les una per una.
La IA com a membre de l'equip, no com a eina
La frontera importa més del que sembla. Quan la IA és «tooling», ningú no respon de la qualitat del que produeix, ningú no en documenta els modes de fallada, ningú no preveu què passa quan cau. Quan és un membre de l'equip amb un rol definit, l'equip s'hi organitza al voltant: quina feina és seva, quina no ho serà mai, i quina redacta perquè un humà la validi.
La regla de «sense autoritat de decisió» és especialment important. La IA pot analitzar, resumir, recomanar, redactar, proposar. No aprova, no desplega, no valida, no fa commit. La frontera de responsabilitat humana queda preservada per construcció. És el mateix principi que apareix en el treball seriós de governança d'IA agèntica: fronteres verificables sobre què pot fer la IA i defaults fail-close per a les accions irreversibles.
Sprints cancel·lables
La cancel·lació és la part que fa més respecte a la majoria d'equips. El reflex àgil estàndard és acabar el sprint i aprendre'n al post-mortem. L'HBMF ho capgira: si a mig sprint l'objectiu deixa de valer el que costa, mata'l. No t'hi aferris pel cost enfonsat.
Això només funciona si l'equip tracta la cancel·lació d'un sprint com un resultat normal, no com un fracàs. I això demana permís cultural, que demana un lideratge que l'avali, que demana que el framework ho faci explícit. La majoria de frameworks àgils no diuen res de cancel·lar sprints. L'HBMF en fa una peça de disseny.
Lideratge a dos rols
La separació Manager + Guru resol una disfunció habitual: la mateixa persona que decideix què es construeix també fa complir el procés, i per tant el compliment del procés cedeix cada vegada que xoca amb el lliurament. Repartir-ho en dos rols, amb el Guru amb dret d'escalada al nivell C, converteix el procés en la preocupació estructuralment protegida.
A la pràctica, el rol de Guru s'assembla més a un engineering manager sènior centrat en les operacions de lliurament que no pas en lliurar funcionalitats — més a prop d'un lead tècnic amb mentalitat SRE que d'un Scrum Master. La disciplina de dashboard (instantànies fins a tres cops al dia, àmpliament visibles) és el que fa el rol útil en lloc de cerimonial.
Què encerta l'HBMF només provisionalment (i on hi ha risc)
L'element que demana més escrutini és la competició governada dins de l'equip. Dos subequips que competeixen, jutjats per l'output, són una estructura de torneig — i la teoria de tornejos mostra efectes clars sobre l'esforç, però també prediu erosió de la cooperació, menys ajuda mútua i més risc de sabotatge si la governança no acompanya.
La resposta de l'HBMF és el rol del Guru més sessions d'ajuda diàries obligatòries («germà gran / germà petit») a hora fixa. La intenció és preservar l'aprenentatge entre subequips i contrarestar la retenció d'ajuda que produeix la competició pura.
Que funcioni o no depèn de l'execució. El plantejament honest — i el del mateix HBMF — és que aquest pilar és contingent. Funciona en contextos amb governança forta, mètriques transparents i cultura de seguretat psicològica. Pot fallar estrepitosament allà on qualsevol d'aquestes tres coses fluixeja. Un CTO que avaluï l'HBMF no hauria de donar per fet que el pilar de la competició és beneficiós a tot arreu.
On no encaixa l'HBMF
El framework no és universal. Alguns contextos on jo aniria amb peus de plom:
Equips petits (< 6 persones). Partir un equip petit en dos subequips que competeixen dona subequips massa petits per funcionar. El pilar de la competició pressuposa prou gent per sostenir dues subunitats viables.
Entorns regulats amb molta càrrega de compliance, on l'accés a la IA està restringit. L'HBMF assumeix que l'assistent d'IA és àmpliament accessible per a l'equip i per a l'alta direcció. En entorns on l'accés a la IA està limitat per classificació de dades o per perímetre regulatori, el mecanisme central del framework queda parcialment neutralitzat. T'hi pots adaptar, però l'adaptació no és trivial.
Dominis madurs, de baixa incertesa. Els sprints de set dies cancel·lables estan optimitzats per a feina d'alta incertesa, augmentable amb IA, on els lots petits preserven valor d'opcions reals. En feina estable i ben coneguda, el sobrecost del cicle pot no compensar.
Organitzacions sense maduresa DevOps. La disciplina de dashboard i la cadència del cicle pressuposen una infraestructura d'enginyeria capaç de suportar integració freqüent i telemetria visible. Si el teu CI/CD no funciona, arregla això primer; el framework no ho compensarà.
Què robaria de l'HBMF
No cal adoptar l'HBMF per aprendre'n. Això és el que jo posaria en marxa aquest any, amb o sense la resta del framework:
- Tracta els assistents d'IA com a contribuïdors amb nom propi, no com a eines. Defineix de què respon la IA, què redacta i què no li tocarà mai. Documenta'n els modes de fallada igual que documentes els rols humans.
- Converteix la cancel·lació d'un sprint en un resultat normal. Abarateix el cost polític d'aturar feina que ja no val la pena.
- Separa l'autoritat de producte de l'autoritat de procés. Encara que sigui de manera informal, assegura't que la mateixa persona no decideix el lliurament i alhora fa complir el procés.
- Fes visibles les llacunes de coneixement. Algun mecanisme setmanal — escrit, públic — perquè cadascú declari què no sap encara. L'empenta conductual importa més que el format.
- Porta l'ESG al model operatiu diari. Si només viu al reporting de portafoli, no fa cap feina.
La lliçó de fons és que el vocabulari àgil estàndard es va dissenyar per a una força de treball que ja no existeix en estat pur. Els equips amb què treballo són híbrids. Els frameworks que ho ignoren generen fricció a cada interfície on la IA és dins del bucle. Els que s'ho prenen seriosament — fins i tot amb arestes per polir, com l'HBMF — fan la feina que toca.
Font: Fradelos, G. The Honey Badger Guide (versió 1.4, 2024). SSRN 6285978.
Si la teva organització d'enginyeria ja treballa amb una plantilla híbrida humà-IA i les pràctiques de gestió no s'han posat al dia, parla amb un CTO per desplegar squads nearshore que ja treballen així.
