Recentment, en una conversa amb alguns companys va sorgir una pregunta que sovint és habitual en el món de l’agilitat. Com podem mesurar l’eficiència del nostre equip?
Ràpidament, la conversa es va dirigir cap al coneixement de la velocitat de l’equip. En aquell moment vaig comentar:
Però l’eficiència no és només una qüestió de velocitat, no? I és que abans de respondre caldria entendre bé què significa que un equip sigui “eficient”.
L’eficàcia està directament relacionada amb l’assoliment dels objectius establerts. Una acció és eficaç quan aconsegueix el resultat esperat, independentment de com s’han utilitzat els recursos disponibles.
En l’àmbit empresarial, l’eficàcia posa el focus en el què. Implica acomplir objectius, assolir metes comercials, entregar funcionalitats compromeses o arribar a determinades fites de negoci. És un criteri clar i fàcil d’avaluar, perquè es vincula directament amb resultats observables i mesurables.
Aquest enfocament és útil per alinear equips amb objectius concrets i focalitzar-los en un objectiu clar. Tanmateix, centrar-se exclusivament en l’eficàcia pot invisibilitzar aspectes rellevants com la sostenibilitat de l’esforç, l’aprofitament del talent o l’ús racional dels recursos.
En entorns organitzatius tradicionals, és habitual considerar que si els objectius s’assoleixen, el sistema funciona. Però aquesta visió pot amagar ineficiències estructurals, costos ocults o competència per l’assignació de recursos que poden provocar problemes greus a mitjà termini.
L’eficàcia s’enfoca doncs en maximitzar els resultats; emprant per això els recursos adequats. I prioritzant en definitiva els resultats sobre l’optimització dels recursos emprats.
L’eficiència té a veure amb l’ús apropiat dels recursos disponibles. En projectes, la primera limitació (o la més evident) arriba amb el cost. Algú decideix que cert producte té un sostre de cost. Bé sigui una licitació, una oferta comercial o qualsevol altre tipus de càlcul previ. Però també és habitual afrontar:
Quan parlem de limitacions però, no ens referim a treballar en l’escassetat, sinó més aviat a parar atenció entre cost i resultat. Tot i que disposis de recursos il·limitats, en eficiència emprem allò que realment és òptim per al valor que pretenem aconseguir.
L’eficiència consisteix a ser conscient de les eines de què disposem, i fer-les servir de la millor forma possible per a obtenir els resultats desitjats.
En entorns complexos i incerts, típics del desenvolupament de producte en els temps actuals, on les bones pràctiques i marcs àgils tenen especial encaix, assolir objectius no sempre implica generar valor real. Sovint, per a mirar de garantir l’evolució del producte, aspectes com l’aprenentatge, el valor obtingut, el feedback continu o la mitigació d’incerteses tenen més repercussió sobre el futur del producte, que el lliurament de funcionalitats.
En contextos de desenvolupament de producte amb agilitat, tant l’eficàcia com l’eficiència només tenen sentit si es relacionen amb el valor generat.
En desenvolupament de producte, no n’hi ha prou amb assolir objectius si això es fa amb un cost excessiu o amb impacte negatiu en la sostenibilitat de l’equip. Tampoc és suficient optimitzar recursos si el resultat no genera valor útil per als usuaris.
Busquem equips ràpids? O busquem equips que treballen en un entorn en què es pot generar un impacte real i sostenible?
L’efectivitat integra el millor de l’eficàcia i de l’eficiència.
En entorns àgils, l’efectivitat es manifesta quan els equips són capaços de lliurar valor de manera sostinguda, amb qualitat, aprenentatge continu i capacitat d’adaptació. L’objectiu real dels equips no és ser eficients ni eficaços, sinó efectius.
En la gestió de productes i projectes és habitual utilitzar la velocitat de lliurament com a indicador bàsic de rendiment. Tanmateix, la velocitat per si sola no descriu l’efectivitat d’un equip ni la qualitat del sistema de treball.
Un equip pot lliurar molt ràpidament i, alhora, generar retreball, deute tècnic o funcionalitats de poc valor. De la mateixa manera, un equip pot avançar a un ritme moderat però estable, lliurant increments de gran qualitat i amb impacte real per als usuaris.
Per aquest motiu, la velocitat s’hauria d’interpretar com un indicador de capacitat (o ritme de treball), i no com una mesura directa d’efectivitat. Per obtenir una visió més completa del rendiment d’un equip, és recomanable incorporar altres paràmetres interessants, com ara:
Aquests elements permeten avaluar l’efectivitat amb un abast més ampli i alineada amb els principis de millora contínua, aprenentatge i sostenibilitat propis dels entorns àgils. Tots aquests indicadors, alguns dels quals els desenvoluparem aquí, ajuden a entendre no només quant es lliura, sinó com de saludable és el sistema de treball.
En aquest article no tractarem tots els indicadors que hem mencionat ara. Pots trobar totes les mètriques definides en detall a l’article següent: Equips efectius. Com avaluar l’efectivitat més enllà de la velocitat.
Quan s’analitza l’efectivitat d’un equip, sovint es posa el focus en el temps de construcció tècnica (cycle time). Limitar la nostra anàlisi de l’efectivitat de l’equip només a aquesta fase ofereix una visió parcial del problema. Hi ha molt més previ a la construcció que determinarà l’èxit o fracàs dels nostres compromisos de construcció.
El cycle time mesura el temps que transcorre des que una tasca s’inicia activament fins que es completa. És un indicador útil per entendre la capacitat de desenvolupament i la fluïdesa del treball dels tècnics.
Ara bé, abans que una necessitat arribi a fase de construcció, acostuma a passar per processos de descoberta, definició, validació i priorització. Aquests processos també consumeixen temps i recursos, i influeixen directament en el valor final que serem capaços de lliurar.
El lead time mesura el temps total des que es detecta o es formula una necessitat fins que aquesta es lliura. Aquest indicador permet analitzar el sistema de treball de forma global, més enllà de la fase tècnica i més enllà de l’equip de desenvolupament.
Un lead time elevat pot retardar l’obtenció de feedback, augmentar la incertesa i incrementar el risc de desalineació amb les necessitats reals dels usuaris o del negoci.
Per aquest motiu, l’optimització del flux de treball ha de considerar tot el procés, des de la idea inicial fins al lliurament. Millorar només la fase de construcció pot resultar en millores tècniques, però no necessàriament una millora en la qualitat dels resultats, el seu valor o la seva idoneïtat.
Descripció del problema
Imaginem una funcionalitat que requereix dues setmanes per a la seva construcció, però passa dos mesos en validacions i prioritzacions abans d’iniciar-se.
Què ens indica això?
El problema no és la capacitat tècnica de l’equip, sinó el temps que la necessitat passa en espera dins del sistema.
Possibles impactes si no es resol
Això pot ser un desencadenant d’efectes negatius importants per al projecte, com per exemple:
Possible solució
Visibilitzar la situació. Estudiar mecanismes de validació menys jeràrquics. Aplicar taulers de treball per la preparació d’aquestes tasques que facin visible la situació d’aquesta i la resta de tasques immerses en aquest procés. Limitar les tasques que estan en procés de validació (aplicar un WIP).
La qualitat del resultat és un factor clau en l’efectivitat real d’un equip. Lliurar ràpidament però amb defectes, mancances tècniques o producte no contrastat generarà treball afegit, augment de costos i pèrdua de confiança.
La Definition of Done (DoD) estableix els criteris que ha de complir un increment per ser considerat complet i usable pels usuaris. Es tracta d’un acord explícit que garanteix un nivell mínim de qualitat compartit per l’equip i l’organització. Alguns d’aquests criteris són:
El DoD ajuda a evitar que el lliurament d’increments acumulin deute tècnic o degradació, que afectin a la qualitat del producte en el seu conjunt. D’aquesta manera, facilita que l’equip pugui treballar d’una forma estable, i tenint en compte aspectes que van més enllà de la pura construcció de noves funcionalitats.
Per aquest motiu, l’acompliment sistemàtic del DoD és també un indicador rellevant d’efectivitat. Un equip que lliura increments que compleixen el DoD redueix necessitats de refactoring, millora la fiabilitat del producte i facilita la presa de decisions basada en increments realment acabats i útils. El DoD també fa explícit què significa que un treball estigui realment acabat, facilitant la transparència entre l’equip i l’organització. Aquesta claredat ajuda a alinear expectatives i a entendre el nivell de qualitat necessari per generar valor de forma sostinguda.
Descripció del problema
Un equip suporta pressions sobre el seu Cycle Time i, per tal de anar més ràpid, decideix saltar-se certes proves que tradicionalment requereixen molt de temps i esforç, com poden ser per exemple les proves de regressió. Immediatament l’organització percep aquest augment de velocitat. Tot fa pensar que l’equip ha millorat notablement en eficiència. Però, és efectiu?
Passat un temps es fa un desplegament d’una funcionalitat important que genera un error crític i inesperat.
Què ens indica això?
L’aparent estalvi de temps inicial acaba repercutint en un deute tècnic i falles d’estabilitat greus en el producte.
Possibles impactes si no es resol
Aquesta relaxació amb el DoD acaba tenint repercussions en l’equip i l’organització, com per exemple:
Possible solució
El DoD és una peça fonamental en el marc de treball. És una garantia per a un equip enfocat en la qualitat, i no només en proporcionar producte ràpidament. Hem d’explicar la importància d’aquesta eina en l’efectivitat de l’equip. I no només al propi equip, sinó a tota l’organització. Aquest és un exemple de eficiència aparent. El que nosaltres busquem en els equips és la garantia de efectivitat real.
En entorns iteratius, cada increment de producte hauria d’aportar algun tipus de valor als seus destinataris. Aquest valor no sempre són increments de producte, poden ser aprenentatges, validació d’hipòtesis o reducció d’incerteses.
Quan els increments no s’utilitzen ni es validen, es perd una de les principals fortaleses dels cicles iteratius: la capacitat de rebre feedback de forma contínua. Sense aquest feedback, augmenta el risc de construir solucions que no responen a necessitats reals dels usuaris.
Per aquest motiu, és útil distingir entre output (el que es construeix) i outcome (l’impacte que genera). Un equip pot tenir molt output i, tanmateix, poc impacte real.
No es tracta només de lliurar producte de per se, sinó de validar si la direcció escollida en l’evolució del producte genera valor real. Un equip pot ser molt efectiu operativament i, per contra, estar construint el producte equivocat. En l’avaluació de l’eficiència d’un equip, pot ser útil observar indicadors relacionats amb el valor obtingut, com ara:
Aquests indicadors ajuden a entendre si l’esforç invertit es tradueix en valor realment útil, i no només en volum de lliuraments.
Descripció del problema
Un equip és capaç de lliurar moltes noves funcionalitats, però aquestes no tenen una coherència adequada amb allò que els usuaris necessiten ara. Els usuaris continuen demanant altres necessitats que no arriben.
Què ens indica això?
L’equip està generant outputs, cosa que podria fer pensar que és eficient. Però aquests outputs no són necessàriament outcomes. El problema, doncs, no és la capacitat de l’equip, sinó la desitjable alineació amb valor real.
Possibles impactes si no es resol
Això pot desencadenar efectes negatius importants per al projecte, com ara:
Possible solució
Tot i que no la única, una possible solució com Scrum Masters, consisteix en tenim una conversa de valor amb el Product Owner, per tal de prendre consciència de la importància d’un Product Backlog ben prioritzat.
Com hem vist al principi de l’article, per obtenir una visió més completa del rendiment d’un equip, és recomanable incorporar altres dimensions interessants, com ara:
Pots trobar informació en detall de les mètriques de les que no hem parlat aquí a l’enllaç següent: Equips efectius. Com avaluar l’efectivitat més enllà de la velocitat.
Mesurar l’eficàcia té sentit quan això ajuda a prendre decisions millors. El mesurament no hauria de convertir-se en un fi en si mateix (La llei de Goodhart: “Quan una mesura es converteix en objectiu, deixa de ser una bona mesura”). Les mètriques, les avaluacions i les eines són mitjans per aconseguir equips cohesionats, comunicacions més valuoses i millors productes.
Treballar amb aquestes mètriques té com a objectiu iniciar converses per la cerca activa de la millora, i no el simple recull d’informació per alimentar un quadre de comandament o per auditar equips. Convertim aquesta informació en catalitzadors que potencien una actitud de col·laboració i entesa mútua entre equips i organització.
Per exemple, si agafem el cas de la diferència entre Lead Time i Cycle Time: Ja hem vist a l’exemple pràctic que un Cycle Time curt no pot garantir valor real i útil per als usuaris, si aquest pateix un Lead Time excessiu. Un cop detectada aquesta problemàtica podem fer seguiment de l’evolució d’aquests dos indicadors al llarg del temps, per tal d’avaluar si les nostres converses i propostes de solució són efectives.
Ni tan sols necessitem una eina tecnològica ni un quadre de comandament per a fer aquest seguiment. Apuntem la data en què es van demanar algunes funcionalitats importants, la data en què es van començar a construir, i la data en què es van lliurar. Fem això durant un temps i observem si el temps d’espera es redueix o no. Es a dir, si el Lead Time s’acosta al Cycle Time.
En cinc minuts i amb post-its (o amb un petit full de càlcul) pots tenir a l’abast una eina potent. I a més serà una eina que cerca la millora no només en l’entorn tècnic, sinó en l’organització sencera.
Què podem fer per a fer partícip l’organització sobre aquesta alerta? La reunió de Retrospectiva podria ser l’espai ideal per a llençar una pregunta: “Hem descobert que el Lead Time és quatre vegades superior al Cycle Time. Què podem fer per a reduir el temps d’espera de les funcionalitats més crítiques?”. I a partir d’aquí fer partícip l’equip. No es tracta de que nosaltres anem amb el problema i la solució. Es tracta que la solució arribi com a producte d’una conversa que ens empodera com a equip a trobar una solució.
Un altre exemple: Quan hem parlat sobre la qualitat del Product Backlog, i la necessitat d’assegurar el seu refinament, hem d’aconseguir que això no es quedi en un simple discurs. Podem proposar, per exemple, que a la Sprint Planning, abans de començar preguntem a l’equip que valori (per exemple de l'1 al 5) la qualitat de la informació del Backlog de cada un dels ítems que es tractaran a la planificació. Això ens dona informació (subjectiva però útil) de si els nostres esforços de refinament van per bon camí o no.
En definitiva, un equip efectiu és aquell que genera un impacte positiu en el producte de manera sostenible en el temps. Aquest és, en el fons, l’objectiu de l’agilitat. Un bon producte es construeix amb bons equips; i bons equips poden existir on l’orientació al valor i la sostenibilitat importen més que la velocitat.
![calaix[À]gil.com](/img/logo.png){kind=logo}
