Escalar l'agile sense SAFe: alternatives lleugeres per a organitzacions d'enginyeria que creixen
He vist aquest patró almenys una dotzena de vegades. Una startup passa d'un equip a tres o quatre. La coordinació comença a grinyolar. Algú proposa SAFe (Scaled Agile Framework) com a solució. Sis mesos després, l'organització d'enginyeria s'ofega entre cerimònies de PI Planning, Agile Release Trains i definicions de rols que ningú no sap retenir. Els enginyers passen més hores en reunions d'alineament que escrivint codi.
SAFe resol un problema real. Però per a la majoria d'organitzacions d'entre 20 i 50 enginyers és la solució equivocada: un marc pensat per a empreses amb centenars d'enginyers, encabit amb calçador en una organització de mida mitjana.
El problema real que SAFe intenta resoldre
Siguem justos amb SAFe i posem nom al que aborda. Quan passes d'un equip a diversos, topes amb problemes de coordinació que abans no existien:
- Dependències entre equips. L'equip A no pot lliurar la seva funcionalitat fins que l'equip B no acabi l'API que necessita. I ningú no se n'assabenta fins a l'últim dia de l'sprint.
- Prioritats que xoquen. Producte diu a un equip que la funcionalitat X és urgent mentre un altre treballa en la infraestructura de què depèn aquesta mateixa funcionalitat — i ningú no ha lligat caps.
- Codi i serveis compartits. Diversos equips despleguen als mateixos serveis i, de tant en tant, es trepitgen els canvis o provoquen regressions inesperades.
- Alineament estratègic. Cada equip optimitza el seu propi backlog sense entendre com encaixa la seva feina amb els objectius trimestrals de l'empresa.
Són problemes reals. Els he viscut tots. La qüestió no és si cal abordar-los, sinó quanta sobrecàrrega de procés justifica la mida de la teva organització.
Per què SAFe es passa de frenada a escala mitjana
SAFe introdueix una estructura enorme: Program Increments, Agile Release Trains, Release Train Engineers, System Demos, Solution Trains i tota una taxonomia de rols i cerimònies. Per a una organització de 200 enginyers en sanitat o finances, potser es justifica. Per a una startup de 30 enginyers amb quatre equips? Per això és un despropòsit:
La càrrega de cerimònies és brutal. El PI Planning, tot sol, és un esdeveniment de dos dies cada 8-12 setmanes. Suma-hi la preparació, el seguiment i les cerimònies recurrents i hauràs afegit dies de reunions per trimestre al calendari de cada enginyer.
La proliferació de rols afegeix cost sense aportar valor. Release Train Engineer, Solution Architect, Epic Owners — en una organització de 30 persones, aquests rols o no existeixen o els assumeix gent que ja va al límit.
Optimitza per a la previsibilitat, no per a la velocitat. Lligar-te a compromisos de PI de 10 setmanes perjudica directament la teva capacitat de reaccionar al que et diu el mercat.
Desincentiva la comunicació informal. «Això és tema de Scrum of Scrums» es converteix en l'excusa per no escriure per Slack a la persona que et pot desencallar ara mateix.
L'alternativa lleugera: el que funciona de debò
He vist funcionar bé els enfocaments següents en organitzacions de 20 a 50 enginyers. Resolen els mateixos problemes de coordinació amb una fracció de la càrrega.
Sincronització setmanal entre equips (30 minuts)
Un representant de cada equip assisteix a una reunió setmanal. L'ordre del dia és senzill:
- Què lliureu aquesta setmana? (2 minuts per equip)
- Què us bloqueja d'un altre equip? (fer aflorar dependències)
- Quins canvis haurien de conèixer els altres? (serveis compartits, canvis d'API, actualitzacions d'infraestructura)
I prou. Ni informes d'estat, ni percentatges de progrés. Si alguna cosa demana una conversa més a fons, convoca-la a part. La sincronització serveix per fer aflorar problemes, no per resoldre'ls.
Taller trimestral de mapa de dependències (mig dia)
Un cop per trimestre, els responsables d'equip i els product managers dibuixen en un tauler compartit la feina prevista per al trimestre següent. No és un pla detallat: és un mapa aproximat de dependències. Hi busques tres coses: dos equips tocant el mateix servei, funcionalitats que depenen de feina no prioritzada i infraestructura compartida sense propietari.
Aquest és el nucli útil del PI Planning, despullat de cerimònia. Mig dia en lloc de dos. Apunta les dependències en un tauler de Miro, assigna responsables i endavant.
Revisions d'sprint conjuntes
En lloc que cada equip faci la seva sprint review aïlladament, organitza una sessió de demos compartida cada dues setmanes (o cada mes, segons la teva cadència). Cada equip ensenya què ha lliurat. El públic són els altres equips.
Això aconsegueix tres coses:
- Crea comprensió compartida. Els enginyers veuen en què treballen els altres equips i com encaixa tot el producte.
- Genera coordinació informal. «Ah, esteu construint això? Nosaltres tenim una necessitat semblant — en parlem després.»
- Apuja el nivell. Quan saps que altres enginyers veuran la teva feina, penses més bé què lliures.
Que sigui curt: 10 minuts per equip com a màxim. Si les demos s'allarguen, deixen de ser útils.
Backlogs compartits per a la feina de plataforma
Si diversos equips depenen d'una infraestructura compartida, crea un backlog de plataforma on qualsevol equip pugui aportar. Encara no et cal un equip de plataforma dedicat, però sí una llista visible i prioritzada de la feina de plataforma, perquè no es perdi entre els backlogs de funcionalitats de cada equip. Assigna-hi un responsable — normalment un enginyer sènior o un tech lead — perquè prioritzi i s'asseguri que la feina avança.
Rituals entre equips
Dues pràctiques lleugeres amb un retorn desproporcionat:
Tech talks. Cada dues setmanes, un enginyer presenta alguna cosa durant 20-30 minuts: una eina nova, una decisió d'arquitectura, un incident en producció. Escampa coneixement i teixeix relacions entre equips.
Revisors creuats rotatius. Assigna revisors d'altres equips als PR que toquen serveis compartits. Així s'enxampen aviat els problemes d'integració i els equips es familiaritzen amb el codi dels altres.
Quan SAFe sí que té sentit
No estic en contra de SAFe per sistema. Hi ha contextos on la càrrega es justifica:
- Organitzacions molt grans (més de 100 enginyers), on la coordinació informal físicament no escala
- Sectors regulats, on els registres d'auditoria, la traçabilitat i la planificació documentada són requisits de compliment normatiu
- Empreses multiproducte, on diferents unitats de negoci han de coordinar llançaments
- Organitzacions amb poca maduresa d'enginyeria, on els equips necessiten més estructura, no menys (tot i que jo diria que hi ha llocs millors per on començar que SAFe)
Però si ets una startup o una scale-up amb entre 20 i 50 enginyers i de 3 a 6 equips, gairebé segur que no et cal.
El principi de fons
El principi de fons és simple: la coordinació ha de ser tan lleugera com la complexitat exigeixi, i ni un gram més. Comença amb el mínim procés viable. Si es trenca, afegeix estructura. Si aguanta, no el toquis.
La pregunta correcta no és «quin procés hauríem d'adoptar?», sinó «quina és la mínima coordinació que ens permet lliurar sense trencar-nos la feina els uns als altres?»
A Conectia, els equips que muntem per a startups europees i nord-americanes sovint s'incorporen just en aquesta etapa de creixement: de tres a cinc equips intentant descobrir com coordinar-se. Els nostres enginyers sèniors de LATAM tenen experiència en entorns distribuïts i multiequip, i aporten patrons pràctics de coordinació que funcionen sense haver d'adoptar cap marc empresarial.
Estàs fent créixer la teva organització d'enginyeria i donant voltes a com coordinar els equips? Parla amb un CTO.
