Sprints, scrum, retrospectives, backlog… Si has sentit aquests termes potser penses que només són cosa d’empreses de software, però també poden ser d’utilitat per als despatxos tècnics.

Scrum va néixer al món del desenvolupament tecnològic, però la lògica que hi ha al darrere (cicles curts, revisió contínua i equips autònoms) descriu com hauria de funcionar un despatx d’arquitectura o enginyeria que vulgui tenir els projectes sota control.

En aquest article no proposem que adoptis Scrum tal com és. Expliquem per què alguns dels seus principis encaixen molt bé amb la realitat del sector AEC i com pots adaptar-los i incorporar-los en la forma de treballar del teu despatx. 

D’on ve Agile i Scrum?

A finals dels anys noranta, els equips de desenvolupament de software estaven atrapats en una paradoxa: com més planificaven al detall, menys s’assemblava el resultat final a allò que el client realment necessitava. Els projectes s’allargaven, els pressupostos s’inflaven i el producte quedava obsolet abans de sortir.

La resposta va ser el Manifest Agile (2001): un conjunt de principis que posen per davant la capacitat d’adaptar-se al canvi per sobre de seguir un pla tancat.

Scrum va ser la implementació més popular d’aquestes metodologies: treballa en cicles curts anomenats sprints (d’una a quatre setmanes), revisa el resultat amb el client al final de cada cicle i ajusta el rumb si cal.

Per què el Scrum pur no funciona en un despatx tècnic

Ser honestos sobre les limitacions d’una metodologia és clau per identificar allò que sí que ens encaixa. Hi ha raons evidents que no permeten aplicar Scrum directament a un estudi d’arquitectura o enginyeria:

• Les fases del projecte no són intercanviables. No pots lliurar l’estructura sense haver tancat el projecte bàsic. Les dependències tècniques i legals marquen un ordre que no és negociable.
  
• El client no és un product owner disponible. En Scrum, el client participa activament en cada sprint. En arquitectura i enginyeria, la propietat sovint no pot o no vol estar present setmanalment en el procés.
  
• Les entregues parcials no sempre aporten valor. Un sprint de software pot entregar una funcionalitat que l’usuari ja pot fer servir. Un sprint d’arquitectura pot no tenir cap entrega visible per al client durant setmanes.
  
• Els equips no acostumen a ser multidisciplinaris i estables. En un despatx, les persones treballen en diversos projectes alhora i la composició de l’equip varia per fases.

Els principis que sí que encaixen: la hibridació Scrumban

El Scrumban és una metodologia híbrida que combina elements de Scrum i de Kanban.

De Scrum pren la cadència de revisió periòdica i la cultura de millora contínua. De Kanban, la visualització del flux de treball i la gestió de les tasques en curs sense imposar cicles tancats. El resultat és un sistema estructurat i flexible.

En un despatx d’arquitectura o enginyeria, podem aplicar la hibridació Scrumban amb aquestes accions:

• Reunió breu setmanal d’equip (15-20 minuts) per revisar l’estat de les tasques actives, identificar bloquejos i redistribuir càrrega si cal. No és una reunió de seguiment jeràrquic: és una posada en comú horitzontal.
  
• Tauler visual de flux amb les tasques de cada projecte organitzades per estat: pendent, en curs, en revisió, entregada. Permet veure d’un cop d’ull on s’acumula la feina i on hi ha marge.
  
• Revisió per fases, no per sprints. En lloc de cicles de temps fix, es fan revisions internes al final de cada fase del projecte (avantprojecte, projecte bàsic, projecte executiu) per avaluar desviacions i ajustar la planificació de la fase següent.
  
• Retrospectiva lleugera al tancament de cada encàrrec, amb tres preguntes simples: què ha anat bé, què ha anat malament i una cosa concreta que canviaríem la pròxima vegada.

Quan aquests elements s’apliquen de manera consistent, el resultat va més enllà de l’eficiència: els tècnics guanyen autonomia sobre la seva feina i l’equip treballa de manera més cohesionada i motivada.

No cal implementar-ho tot de cop. Molts despatxos comencen pel tauler visual i la reunió setmanal, i amb això ja guanyen visibilitat sobre projectes.

Com saber si Scrumban està funcionant? 4 indicadors

Adoptar una metodologia sense mesurar-ne l’impacte és fer un acte de fe. Aquests són els indicadors que permeten saber si la hibridació Scrumban està aportant valor real al teu despatx:

1. Reducció de tasques bloquejades. Si el tauler visual mostra menys tasques encallades setmana rere setmana, la metodologia funciona.
   
2. Menys desviacions de termini per fase. Compara la data prevista i la data real d’entrega de cada fase. Si la franja es redueix, s’està millorant la planificació.
   
3. Hores no facturades per retreball. Els retreball (rework) és símptoma d’haver fet una revisió massa tard. Si disminueixen, les revisions per fase funcionen.
   
4. Percepció de l’equip. Una pregunta directa cada tres mesos: “Tens clar en tot moment quines són les teves prioritats?” Si la resposta és positiva, la metodologia funciona.

Cap d’aquests indicadors necessiten eines complexes per mesurar-los, però sí que és imprescindible tenir les dades disponibles i actualitzades en temps real.

Posa els principis Agile en pràctica amb Coneix

L’ERP de Coneix et permet fer seguiment del rendiment de cada etapa dels projectes: hores imputades per fase, desviacions respecte a la planificació i distribució de la càrrega per persona, entre d’altres.

Amb aquesta visibilitat de les dades clau del teu negoci, les revisions setmanals d’equip passen de ser una conversa sobre percepcions a ser una decisió basada en dades.

A Coneix fa anys que planifiquem amb les metodologies Agile Scrum + Kanban. Si vols veure com ho apliquem i com t’ajuda l’ERP a tenir les dades del teu equip sempre actualitzades, t’ho mostrem en una demo sense compromís: