Escalar Agile Sense SAFe: Enfocaments Lleugers per a Organitzacions d'Enginyeria en Creixement
Aquí hi ha un patró que he vist repetir-se almenys una dotzena de vegades. Una startup creix d'un equip a tres o quatre. La coordinació es torna desordenada. Algú proposa SAFe (Scaled Agile Framework) com a solució. Sis mesos després, l'organització d'enginyeria s'ofega en cerimònies de PI Planning, Agile Release Trains, i definicions de rols que ningú pot seguir. Els enginyers passen més temps en reunions d'alineació que escrivint codi.
SAFe resol un problema real. Però per a la majoria d'organitzacions d'enginyeria d'entre 20 i 50 enginyers, és la solució equivocada — un marc dissenyat per a empreses amb centenars d'enginyers, encaixat en una organització de mida mitjana.
El Problema Real que SAFe Intenta Resoldre
Siguem justos amb SAFe anomenant el que aborda. Quan passes d'un equip a múltiples equips, tens 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 acabi l'API que necessiten. Ningú ho sap fins a l'últim dia del sprint.
- Prioritats conflictives. L'equip de producte diu a l'Esquadra 1 que la funcionalitat X és urgent, mentre l'Esquadra 2 treballa en la infraestructura de la qual depèn la funcionalitat X — però ningú ha connectat els punts.
- Codebases i serveis compartits. Múltiples equips desplegant als mateixos serveis, de vegades sobreescrivint els canvis dels altres o causant regressions inesperades.
- Alineació estratègica. Cada equip optimitza per al seu propi backlog sense entendre com el seu treball connecta amb els objectius trimestrals de l'empresa.
Aquests són problemes reals. He viscut tots ells. La pregunta no és si cal abordar-los. És quanta sobrecàrrega de procés es justifica per a la teva mida d'organització.
Per Què SAFe S'excedeix a Escala Mitjana
SAFe introdueix una estructura massiva: 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 justificat. Per a una startup de 30 enginyers amb quatre esquadres? Aquí és per què és absurd:
La sobrecàrrega de cerimònies és brutal. El PI Planning per si sol és un event de dos dies cada 8-12 setmanes. Afegint la preparació, el seguiment i les cerimònies contínues, has afegit dies de reunions per trimestre al calendari de cada enginyer.
La proliferació de rols afegeix cost sense valor. Release Train Engineer, Solution Architect, Epic Owners — en una organització de 30 persones, aquests rols o bé no existeixen o bé estan ocupats per persones ja sobrecarregades.
Optimitza per a la previsibilitat en lloc de la velocitat. Bloquejar-se en compromisos de PI de 10 setmanes perjudica activament la teva capacitat de respondre als comentaris del mercat.
Desanima la comunicació informal. "Això és un tema de Scrum of Scrums" es converteix en una excusa per no fer Slack a la persona que et pot desencallar ara mateix.
L'Alternativa Lleugera: El Que Realment Funciona
He vist els enfocaments següents funcionar bé per a organitzacions de 20-50 enginyers. Resolen els mateixos problemes de coordinació amb una fracció de la sobrecàrrega.
Sincronització Setmanal Entre Equips (30 minuts)
Un representant de cada equip s'uneix a una reunió setmanal. L'ordre del dia és senzill:
- Què esteu lliurant aquesta setmana? (2 minuts per equip)
- Què us bloqueja d'un altre equip? (superficiar dependències)
- Què canvia que els altres haurien de saber? (serveis compartits, canvis d'API, actualitzacions d'infraestructura)
Això és tot. Sense informes d'estat. Sense percentatges de progrés. Si alguna cosa necessita una discussió més profunda, programa un seguiment. La sincronització és per superficiar, no per resoldre.
Taller Trimestral de Mapeig de Dependències (mig dia)
Un cop per trimestre, els responsables d'equip i els gestors de producte mapegen el treball planificat per al pròxim trimestre en un tauler compartit. No un pla detallat — un mapa aproximat de dependències. Estàs buscant: dos equips canviant el mateix servei, funcionalitats que depenen de treball no prioritzat, infraestructura compartida que ningú té en propietat.
Aquest és el nucli útil del PI Planning, desproveït de cerimònia. Mig dia en lloc de dos dies. Escriu les dependències en un tauler de Miro, assigna propietaris, i continua.
Revisions de Sprint Conjuntes
En lloc de cada equip fer la seva revisió de sprint de manera aïllada, fes una sessió de demo compartida cada dues setmanes (o mensualment, depenent de la teva cadència). Cada equip mostra el que ha lliurat. El públic és els altres equips.
Això fa tres coses:
- Construeix comprensió compartida. Els enginyers veuen en què treballen els altres equips i com es connecta el producte.
- Crea coordinació informal. "Oh, esteu construint això? Tenim una necessitat similar — parlem després."
- Eleva la qualitat. Quan saps que altres enginyers veuran el teu treball, ets més intencionat sobre el que lliures.
Mantén-ho ajustat. 10 minuts per equip, màxim. Si les demos s'allarguen, deixen de ser útils.
Backlogs Compartits per al Treball de Plataforma
Si múltiples equips depenen d'infraestructura compartida, crea un backlog de plataforma al qual qualsevol equip pugui contribuir. Encara no necessites un equip de plataforma dedicat. Però necessites una llista visible i prioritzada del treball de plataforma perquè no es perdi en el backlog de funcionalitats de cada equip. Assigna un propietari — generalment un enginyer senior o tech lead — per prioritzar i assegurar que el treball es recull.
Rituals Entre Esquadres
Dues pràctiques lleugeres que aporten dividends desproporcionats:
Tech talks. Cada dues setmanes, un enginyer presenta alguna cosa durant 20-30 minuts. Una nova eina, una decisió arquitectònica, un incident en producció. Difon el coneixement i construeix relacions entre equips.
Revisors rotatius. Assigna revisors entre equips per als PRs que toquen serveis compartits. Això detecta els problemes d'integració d'hora i construeix familiaritat entre equips.
Quan SAFe Realment Té Sentit
No estic en contra de SAFe de manera categòrica. Hi ha contextos on la sobrecàrrega es justifica:
- Organitzacions molt grans (100+ enginyers) on la coordinació informal físicament no pot escalar
- Indústries regulades on les pistes d'auditoria, la traçabilitat i la planificació documentada són requisits de compliment
- Empreses multiproducte on diferents unitats de negoci necessiten coordinar els llançaments
- Organitzacions amb baixa maduresa d'enginyeria on els equips necessiten més estructura, no menys (tot i que argumentaria que hi ha millors llocs per començar que SAFe)
Però si ets una startup o scale-up amb 20-50 enginyers i 3-6 equips, gairebé amb tota certesa no el necessites.
El Principi Darrere de Tot Això
El principi subjacent és simple: la coordinació hauria de ser tan lleugera com la complexitat requereixi i no més pesada. Comença amb el procés mínim viable. Si es trenca, afegeix estructura. Si aguanta, deixa-ho estar.
La pregunta correcta no és "quin procés hauríem d'adoptar?" És "quina és la quantitat mínima de coordinació que ens permet lliurar sense trencar el treball dels altres?"
A Conectia, els equips que construïm per a startups europees i americanes sovint s'uneixen exactament en aquesta etapa de creixement — tres a cinc esquadres esbrinin com coordinar-se. Els nostres enginyers sèniors de LATAM tenen experiència treballant en configuracions distribuïdes i multiequip, i aporten patrons pràctics de coordinació que no requereixen adoptar un marc empresarial per funcionar.
Estàs fent créixer la teva organització d'enginyeria i necessites enginyers que sàpiguen treballar entre equips? Parla amb un CTO — els nostres enginyers sèniors s'integren en configuracions multiequip i aporten experiència de coordinació des del primer dia.
