El Framework Honey Badger: Gestionar Equips Híbrids Humà-IA el 2026
Pràcticament tots els frameworks àgils en ús a producció avui es van dissenyar abans que els assistents d'IA formessin part del flux de treball diari. Scrum, SAFe, Kanban, PRINCE2 — tots assumeixen que el treball el fan humans, amb les eines fora del límit de l'equip. La IA apareix a aquests frameworks com a "tooling", o com a màxim com una capa de productivitat.
Aquesta assumpció s'està esquerdant. A la majoria d'organitzacions d'enginyeria amb què treballo, l'assistent d'IA no és una eina al costat del desenvolupador — forma part del bucle. Agafa tickets, redacta codi, resumeix context, executa anàlisis, escriu documentació. Tractar-lo com a tooling fora de banda produeix friccions mesurables: artefactes de procés que ignoren on passa el treball realment, mètriques de rendiment que no veuen la contribució de la IA, buits de responsabilitat quan el treball produït per la IA falla.
El Honey Badger Management Framework (HBMF), presentat per Georgios Fradelos el 2024, adopta la postura 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 al model operatiu en lloc de bolcar-lo com una capa de reporting. Val la pena entendre'l, encara que no el vulguis adoptar sencer, perquè les decisions de disseny revelen els forats reals dels frameworks àgils convencionals quan la IA hi és al bucle.
Què té de diferent HBMF
Si traiem la nomenclatura, HBMF és un conjunt petit de decisions amb opinió:
Sprints de set dies cancel·lables. Més curts que el default de dues setmanes de Scrum, amb permís explícit per cancel·lar un sprint a meitat si l'objectiu ja no val la pena. L'argument econòmic és real: la teoria d'opcions reals — els lots petits preserven l'opcionalitat, i els sprints llargs la destrueixen.
Dos sub-equips competint dins d'un mateix equip. Mateix problema, dos intents en paral·lel, jutjats pel resultat. És competició governada: una estructura de torneig dins del límit de l'equip, amb governança explícita per evitar el mode de fallada (sabotatge, erosió de l'ajuda, col·lapse de la seguretat psicològica).
Integració d'IA obligatòria. Cada equip té un assistent d'IA designat per al treball de coneixement. La direcció utilitza el mateix assistent. La IA no té autoritat de decisió — això és crític — però es tracta com un contribuïdor el resultat del qual forma part del lliurable de l'equip, no un truc privat de productivitat d'algú.
Declaracions obligatòries de buits de coneixement. Tot membre de l'equip, setmanalment, declara una força de camp estret i un buit de coneixement. Públic, visible al dashboard, no estigmatitzat. El sentit és fer aflorar el que la gent encara no sap abans que es converteixi en defecte.
Dos rols de lideratge, no un. Un Manager té els requisits de producte i les decisions de recursos. Un Guru té el compliment de procés, la transferència de coneixement i la transparència del dashboard, amb dret d'escalada al nivell C. La separació és intencional: separar l'autoritat de producte de l'autoritat de procés evita el conflicte d'interès que arrossega els frameworks on una sola persona fa les dues coses.
ESG incrustada al model operatiu. Eficiència energètica, transparència i accessibilitat són restriccions a nivell de sprint, no de reporting de portfolio. L'assistent d'IA, usat per tothom, és part de l'argument ESG en si mateix — redueix el cost energètic marginal del treball cognitiu en comparació amb escalar plantilla.
Què encerta HBMF
Algunes d'aquestes decisions són no-òbvies i val la pena entendre-les una a una.
IA com a membre d'equip, no com a eina
La frontera importa més del que sembla. Quan la IA és "tooling", ningú no és propietari de la qualitat del seu output, ningú no documenta els seus modes de fallada, ningú no planifica les seves caigudes. Quan és un membre d'equip amb un rol definit, l'equip planifica al seu voltant: quina feina és seva, quina no és mai seva, quina redacta i un humà signa.
La regla de "no autoritat de decisió" és particularment important. La IA pot analitzar, resumir, recomanar, redactar, proposar. No aprova, no envia, no signa, no fa commit. La frontera de responsabilitat humana es preserva per construcció. És el mateix principi que apareix al treball seriós de governança d'IA agentica — fronteres verificables sobre què pot fer la IA, defaults fail-close per a accions irreversibles.
Sprints cancel·lables
La cancel·lació és la part on la majoria d'equips es mostren incòmodes. El reflex àgil estàndard és acabar el sprint i aprendre del post-mortem. HBMF inverteix això: si l'objectiu deixa de valer el cost a meitat de sprint, mata'l. No és cost enfonsat.
Això només funciona si l'equip tracta la cancel·lació com un resultat normal i no com un fracàs. Això requereix permís cultural, que requereix lideratge que ho avali, que requereix que el framework ho faci explícit. La majoria de frameworks àgils callen sobre la cancel·lació de sprints. HBMF en fa una característica.
Lideratge a dos rols
La separació Manager + Guru resol una disfunció comuna: la mateixa persona que decideix què construir també fa complir el procés, cosa que vol dir que el compliment de procés es compromet sempre que xoca amb el lliurament. Separar-ho en dos rols, amb el Guru tenint dret d'escalada al nivell C, fa que el procés sigui la preocupació estructuralment protegida.
A la pràctica, el rol de Guru s'assembla a un Engineering Manager sènior centrat en operacions de lliurament en lloc del lliurament de funcionalitat — més proper a un lead tècnic amb mentalitat SRE que a un Scrum Master. La disciplina de dashboard (snapshots fins a tres cops al dia, àmpliament visibles) és el que fa que el rol sigui útil i no cerimonial.
El que HBMF encerta provisionalment (i el que té risc)
L'element que demana més escrutini és la competició governada intra-equip. Dos sub-equips competint, jutjats per output, és una estructura de torneig — i la teoria del torneig mostra efectes clars d'esforç, però també prediu erosió de la cooperació, reducció de l'ajuda i augment del risc de sabotatge sota la governança equivocada.
La resposta de HBMF és el rol del Guru més sessions diàries d'ajuda obligatòries ("germà gran / germà petit") a una hora fixa. La intenció és preservar l'aprenentatge entre equips i contrarestar l'efecte de retenció d'ajuda que produeix la competició pura.
Si això funciona depèn de l'execució. La interpretació honesta — i la pròpia interpretació de 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 greument en contextos on cap d'aquestes és feble. Els CTO que avaluen HBMF no haurien d'assumir que el pilar de competició és universalment beneficiós.
On no encaixa HBMF
El framework no és universal. Alguns contextos on aniria amb cura:
Equips petits (< 6 persones). Dividir un equip petit en dos sub-equips competidors produeix sub-equips massa petits per funcionar. El pilar de competició assumeix prou capçal per donar suport a dues sub-unitats viables.
Entorns regulats amb molta compliance on l'accés a IA està limitat. HBMF assumeix que l'assistent d'IA és àmpliament accessible a l'equip i a la direcció. En entorns on l'accés a IA està restringit per classificació de dades o frontera reguladora, el mecanisme central del framework queda parcialment neutralitzat. Es pot adaptar, però l'adaptació no és trivial.
Dominis madurs i de baixa incertesa. El sprint de set dies cancel·lable està optimitzat per a treball d'alta incertesa i augmentable amb IA on els lots petits preserven valor d'opcions reals. En treball estable i ben entès, el cost del cicle pot no compensar.
Organitzacions sense maduresa DevOps. La disciplina de dashboard i la cadència del cicle assumeixen que la infraestructura d'enginyeria subjacent pot suportar integració freqüent i telemetria visible. Si el teu CI/CD està trencat, arregla'l primer; el framework no ho compensarà.
Les conclusions concretes
No has d'adoptar HBMF per aprendre'n. Les adaptacions concretes que la majoria d'organitzacions d'enginyeria haurien de considerar el 2026:
- Tracta els assistents d'IA com a contribuïdors amb nom, no com a eines. Defineix què té la IA, què redacta, què no té mai. Documenta els seus modes de fallada al costat dels rols humans.
- Fes que la cancel·lació de sprint sigui un resultat normal. Redueix 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 informalment, assegura't que una sola persona no és alhora la decididora de lliurament i l'executora del procés.
- Fes visibles els buits de coneixement. Algun mecanisme setmanal — escrit, públic — perquè la gent declari què encara no sap. El nudge conductual importa més que el format.
- Mou ESG al model operatiu diari. Si només viu al reporting de portfolio, no està fent la feina.
La lliçó més profunda és que el vocabulari àgil estàndard es va dissenyar per a una força de treball que ja no existeix en forma pura. Els equips amb què treballo són híbrids. Els frameworks que ho ignoren produeixen fricció a cada interfície on la IA està al bucle. Els frameworks que s'ho prenen seriosament — fins i tot els que tenen vores aspres, com HBMF — estan fent el tipus correcte de feina.
Font: Fradelos, G. The Honey Badger Guide (Versió 1.4, 2024). SSRN 6285978.
Si la teva organització d'enginyeria opera amb una força de treball híbrida humà-IA i les pràctiques de gestió no s'han posat al dia, parla amb un CTO sobre desplegar squads nearshore que ja treballen així.
