L’Agile no és córrer més: és aprendre abans
Si treballes en un equip de tecnologia, és probable que hagis sentit aquestes paraules més d’una vegada. Però, realment sabem què significa treballar amb l’Agile o només estem seguint una recepta? En aquest post repasem els conceptes que val la pena entendre abans de parlar d’eines o intel·ligència artificial.
Quan parlem d’Agile apareixen ràpidament paraules com Sprint, Daily, backlog, Scrum Master o Jira. Però l’Agile no consisteix a omplir l’agenda de reunions ni a moure targetes d’una columna a l’altra. Per a mi, la idea és molt més senzilla:
Fer alguna cosa petita, comprovar si aporta valor, aprendre i decidir el següent pas. I repetir.
Ara, a més, tenim una eina que pot accelerar bastant aquest cicle: la intel·ligència artificial. No per substituir l’equip, sinó per reduir tasques mecàniques i permetre-nos dedicar més temps a pensar, col·laborar i prendre decisions.
L’Agile no és només Scrum
Tot i que moltes vegades utilitzem l’Agile i el Scrum com si fossin la mateixa cosa, no ho són. L’Agile és una manera de treballar basada en la col·laboració, la lliurància freqüent de valor i la capacitat d’adaptar-nos als canvis. El Scrum és un dels marcs que podem utilitzar per portar aquestes idees a la pràctica, però no és l’únic:
| Enfocament | Idea principal |
|---|---|
| Scrum | Treballar en cicles curts anomenats Sprints |
| Kanban | Visualitzar i millorar el flux de treball |
| XP | Aplicar pràctiques tècniques orientades a la qualitat i la lliurància freqüent |
| Scrumban | Combinar elements de Scrum i Kanban |
El que importa no és complir un framework al mil·límetre, sinó aconseguir lliurar, rebre feedback i adaptar-nos.
Com es treballa?
En lloc d’intentar definir tot un producte des de l’inici, l’Agile proposa avançar en petits passos: Prioritzar → Construir → Validar → Aprender → Adaptar. Si utilitzem el Scrum, aquest cicle s’organitza en Sprints amb aquests moments:
- Sprint Planning: decidim què volem aconseguir.
- Daily: revisem com avançem i si hi ha bloquejos.
- Sprint Review: mostrem el que hem construït i recollim feedback.
- Retrospèctiva: analitzem com podem treballar millor.
El problema apareix quan aquestes reunions es converteixen en un tràmit. Una Daily no hauria de ser una reunió per dir a un responsable què fem ahir, i una retrospèctiva serveix de poc si trobem els mateixos problems Sprint rere Sprint i mai no fem res amb ells. Les cerimònies tenen sentit quan ens ajuden a inspeccionar i adaptar la nostra manera de treballar.
Quines figures podem trobar?
Si parlem de Scrum, trobem tres responsabilitats principals:
| Figura | Responsabilitat principal |
|---|---|
| Product Owner | Prioritzar i maximitzar el valor del producte |
| Scrum Master | Ajudar l’equip a treballar correctament amb el Scrum |
| Membres de l’equip | Construir el producte, fer les tasques del projecte i decidir com fer el treball |
Però en un equip real podem trobar molts més perfils:
Perfils orientats al producte: UX/UI Designer — dissenya l’experiència. Business Analyst — tradueix necessitats en requisits. QA o Tester — garanteix que el que es construeix funciona.
Perfils tècnics: Tech Lead — defineix la direcció tècnica. DevOps — cura la infraestructura i el desplegament. Data Engineer — prepara dades i canonades. AI Engineer — integra models d’IA.
Altres rols clau: Stakeholders — representen els interessos del negoci. Usuaris — la raó d’existència del producte. El seu feedback és la font principal del cicle Agile.
Un equip Agile funciona millor quan diferents especialitats treballen juntes al voltant d’una mateixa finalitat.
Les eines ajuden, però no fan l’Agile
Instal·lar Jira no converteix automàticament una organització en Agile. Les eines haurien d’ajudar-nos a fer que el treball i la informació siguin més visibles:
| Necessitat | Algunes eines |
|---|---|
| Planificació | Jira, Azure DevOps, GitHub Projects, Trello |
| Documentació | Confluence, Notion |
| Comunicació | Microsoft Teams, Slack |
| Desenvolupament | GitHub, GitLab, Bitbucket |
| CI/CD | GitHub Actions, GitLab CI/CD, Jenkins |
| Disseny | Figma, Miro |
| Mètriques | Grafana, Power BI, dashboards |
| IA | Copilots, assistents i agents |
L’eina concreta és secundària. El que importa és evitar que conèixer l’estat d’un projecte implici revisar cinc aplicacions diferents i preguntar a mitja organització.
Agile + IA
Aquí és on crec que la cosa comença a posar-se especialment interessant. En un equip Agile hi ha molt de treball al voltant del treball: resumir reunions, actualitzar tiquets, ordenar feedback, redactar històries, preparar criteris d’acceptació, crear casos de prova, buscar documentació i generar informes. Moltes d’aquestes tasques poden accelerar-se amb intel·ligència artificial.
Per exemple, eines com GitHub Copilot o Cursor poden generar tests d’acceptació directament des de l’història d’usuari, mentre que un LLM pot analitzar comentaris d’usuaris per agrupar problemes comuns. També pot ajudar-nos abans d’una Planning detectant històries massa grans o requisits ambigus, i en una retrospèctiva pot agrupar comentaris similars perquè l’equip se centri a parlar dels problemes.
En el desenvolupament pot ajudar-nos a generar codi, proves o propostes de canvis. Si a més l’equip treballa amb feature flags o branques curtes tipus trunk-based, el cicle de lliurament es torna encara més curt: menys temps entre escriure codi i comprovar si funciona en producció.
El cicle podria passar d’alguna cosa com:
Història → Desenvolupament → Pull Request → Review
a:
Història → IA proposa → Equip revisa → IA executa → Persona valida
La IA accelera algunes parts del procés.
Però hi ha una diferència important:
La IA ens pot ajudar a produir. No hauria de decidir què val la pena produir.
El risc de córrer més
Aquí és probablement el punt més important. Si utilitzem la IA només per generar més històries, més codi, més documentació i més funcionalitats, podem augmentar molt la nostra capacitat de producció. Però això no significa que estiguem construint millors productes.
Un indicador habitual és la velocity: quantes històries completam per Sprint. Si la IA ens permet lliurar el doble, la velocity puja. Però si aquestes històries no resolen problemes reals, estem acumulant deute disfressat de productivitat. Podem tenir un Sprint amb 40 històries tancades i cap que l’usuari hagi demanat.
Podem córrer molt…
…en la direcció equivocada.
I precisament allà l’Agile continua tenint tot el sentit.
Si costa menys i menys desenvolupar una funcionalitat, la pregunta important deixa de ser:
Podem construir-lo?
I comença a ser:
Mereix la pena construir-lo?
La IA pot analitzar, resumir, proposar i executar.
Però seguim necessitant persones que entenguin l’usuari, qüestionin idees, prioritzin i tinguin decisions.
Un primer pas concret
Si demà tens una Planning o una retrospèctiva, prova alguna cosa senzilla: abans d’estimar o prioritzar, pregunta’t amb l’equip “per què aquesta història i no una altra?”. No necessites instal·lar res ni canviar el teu procés. Només una pregunta que obliga a connectar el treball amb el valor real. Si la resposta no és clara, potser aquella història no hauria d’estar al Sprint.
L’Agile que ve
No crec que el futur de l’Agile consisteix a inventar més cerimònies. Crec que estarà en aconseguir que persones, eines i agents comparteixin millor el context: que la IA pugui preparar informació abans d’una reunió, que relacioni feedback amb funcionalitats, que un agent pugui executar tasques ben definides. I que les persones puguem concentrar-nos més a descobrir quin problema realment mereix la nostra atenció.
Perquè l’Agile mai va tractar simplement de treballar més ràpid. Va tractar de reduir la distància entre fer alguna cosa i descobrir si estàvem fent el correcte. I allà la IA pot convertir-se en una gran aliada.
Glossari ràpid
Si algun terme del post et resulta nou:
| Terme | En una frase |
|---|---|
| LLM | Model d’IA entrenat amb text (GPT, Claude, Llama) que genera, resumeix o analitza contingut. |
| Token | Unitat de processament del model — una paraula pot ocupar un o diversos tokens. |
| Velocity | Mètrica de Scrum: històries completades per Sprint. Perillosa si és l’únic indicador. |
| Pull Request | Proposta de canvis en codi perquè l’equip ho revisi abans d’integrar. |
| Feature flags | Interruptors per activar/desactivar funcionalitats sense redeploy. |
| Trunk-based | Treballar en una branca principal amb branques molt curtes. |
| CI/CD | Integració i desplegament automàtics i freqüents. |