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é que significa que un equip sigui “eficient”.
L’eficàcia està directament relacionada amb l’assoliment dels objectius establerts. Portat a l’extrem, de forma aparent l’eficàcia no contempla limitacions; i fa ús dels mitjans que siguin necessaris per assolir els objectius establerts.
L’eficàcia és el somni humit per a tot mànager tradicional que s’enfronta a una planificació. Per a qualsevol projecte, temps, recursos i costos il·limitats. Consisteix a utilitzar el que necessitis per a tenir el que desitges de la millor forma possible.
Poc importa en eficàcia si aquests mitjans s’estan emprant d’una forma òptima, o tan sols apropiada. Si afavoreix l’assoliment dels objectius, està bé. Si ho penses bé, això no és tan estrany com puguis imaginar-te. He viscut moltes situacions en què persones d’un equip (òbviament no autogestionats) treballaven en entorns en què el seu talent i les seves habilitats eren infrautilitzats. El projecte “va bé” des de la perspectiva de l’eficàcia, per tant, tot estava OK. Però en realitat s’estava coent un desastre respecte a les persones que hi treballaven. De tota manera, a gran escala, en el món real sempre hi ha limitacions. Ens hem acostumat com a societat a aspirar a tot, però sabent que no hi ha il·limitats recursos.
L’eficiència te 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 X. Bé sigui una licitació, una oferta comercial o qualsevol altre càlcul màgic. Però també és comú lidiar amb:
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.
Si en el nostre quadre de comandament del projecte ens fixem únicament en el velocímetre, potser ens trobarem que un equip eficient és “lent” comparat amb un equip eficaç. Hem de comprendre que ambdós equips no estan jugant amb les mateixes regles, ni es focalitzen en els mateixos paràmetres. L’equip eficient té restriccions i es focalitza en esprémer al màxim les eines de que disposa. Mentre que un equip eficaç no té limitacions i utilitza les eines per maximitzar el resultat desitjat
Seria convenient llavors, ni que sigui per justícia poètica, fixar-nos en altres paràmetres que, a més, són molt interessants, i ens ajudaran a tenir una imatge 360º de l’eficiència del nostre equip. Alguns d’aquests paràmetres poden ser:
Creieu que és just per a l’equip que centrem els nostres esforços en el control del temps que triga a construir certa necessitat? Què passa amb tot el procés previ? No mereix certa anàlisi també? El cycle time correspon al temps de construcció de la necessitat, un cop s’autoritza la construcció d’aquesta. Aquest temps està focalitzat en els tècnics.
Però, des del moment en què un stakeholder verbalitza una necessitat, s’enceta un procés que té com a principal objectiu determinar la seva idoneïtat en el conjunt del producte. Tant pel que fa a l’encaix amb la part ja construïda, com l’encara pendent.
Aquest procés té un flux de treball que bàsicament persegueix l’obtenció de la informació necessària per poder determinar aquesta idoneïtat. Per tant, aquest procés comporta la feina de persones durant un temps determinat. I com a tal, pot o ha de ser avaluat per tal de cercar millora aquí també.
No seria just un procés de definició i priorització de les necessitats lent o amb mancances greus, en contrapartida a un procés de construcció tècnica ultramonitoritzat. Error habitual aquí dels Scrum Masters, que obliden la 1a premissa de la seva funció: Explicar Scrum a tota l’organització
El lead time correspon a tot el procés, d’ençà que es verbalitza la necessitat, fins que aquesta és finalitzada i empaquetada amb un llacet per a l’entrega. Tot el procés és susceptible de millora. Un lead time lent provoca incoherències en la priorització, i afecta negativament la qualitat del valor lliurat.
Hauríem de ser completament autoorganitzats com a equip. Però malauradament hi ha cops que l’autoorganització s’acaba on l’organització imposa formes de fer comunes. No estic dient que m’agradi ni que hi hagi mecanismes per millorar això. Dic que passa molt sovint.
Per exemple, hi ha organitzacions que no comprenen bé les avantatges de fer servir històries d’usuari. El Product Backlog pot ser una eina que ajuda veritablement a l’equip, amb necessitats clares, actuals, ben informades (ready), i amb un mínim valor. O pot ser una mena de cul-de-sac de peticions atòmiques sense ordre.
Els Scrum Boards dels equips són un reflex del Product Backlog. Si el Product Backlog no està bé, els Sprints Backlogs i els taulers tampoc estaran bé. Com a Scrum Masters hem de detectar això, i fer propostes que millorin la qualitat de les eines dels equips. Scrum Boards nets i clars. Sprints amb objectius clars, abastables i que generin increments de valor. I Products Backlogs centrats en la necessitat, criteris d’acceptació i el MVP.
Com a Scrum Masters faríem bé a tenir en el nostre quadre de comandament, indicadors sobre la qualitat de les eines operatives dels nostres equips
Un equip que prima l’eficacia potser no veurà amb bons ulls que existeixin normes i condicions necessàries que puguin fer perillar l’assoliment dels objectius. Un equip eficient és conscient d’aquestes tasques necessàries, i adaptarà la seva operativa per tal de tenir-les present com a part del resultat.
És DoD tot allò que l’organització (per ex: CI/CD), el client (per ex: usabilitat i accessibilitat) l’estat (per ex: RGPD), el mateix equip (per ex: API, escalabilitat o qualitat del resultat) o altres interessats creuen necessari per a tenir els resultats desitjats.
A més, dins d’aquest paraigües sempre hem de fer èmfasi a tot el relatiu a la qualitat del resultat (qualitat tècnica i fiabilitat del resultat). Un producte fiable és necessari sempre. Les proves a múltiples nivells, els benchmarks de rendiment i, de forma especialment important en cicles iteratius, la garantia de regressió del resultat. El DoD ve a dir que no és suficient tenir un producte que funciona, sinó que a més aquest és útil en qualsevol situació
Quan ens pregunten com podem mesurar l’eficiència del nostre equip, faríem bé en tenir valors sobre l’acompliment del DoD
Els bugs. Seria molt innocent pensar que allò que hem lliurat al sprint anterior, per molt rigorosos que siguem en assegurar-ne la qualitat, no generarà cap mena d’error o de sorpresa un cop l’usuari en faci ús. Com a Scrum Masters, en la nostra avaluació de l’eficiència de l’equip, hem de mesurar els bugs. Saber-ne l’origen, la via per la qual es resoldran, i l’impacte que això té sobre la feina de l’equip i dels resultats esperats en el proper sprint.
No és objectiu aquí explicar els mecanismes per “conviure” amb els bugs. Però crec que sempre és bo comentar algunes coses que crec que són importants:
Sigui com sigui, crec que l’important és fer estimació d’aquesta feina imprevista que ens arriba. I el millor que podem fer és negociar amb el Product Owner. Amb l’estimació es pot explicar que els bugs també són feina de persones. I la feina mai és a cost 0.
Si tens un sistema iteratiu consistent en què, de forma cíclica, dones una porció del producte, aquesta porció ha de ser útil per als seus destinataris. Si no ho és, aquell lliurament anirà a parar a un calaix a l’espera d’altres lliuraments posteriors, o pitjor encara, a tenir el producte completament enllestit.
Si els nostres lliuraments van a parar a calaixos, no tenim feedback ni revisió que ens permeti detectar i corregir desviacions. I això comporta, molt probablement, que el projecte acabarà malament.
El procés per la correcta definició del MVP forma part del Lead Time. En el nostre procés d’avaluació del nostre equip hauríem de contemplar indicadors sobre la definició del MVP i el seu acompliment al lliurament a cada cicle
Per últim, l’avaluació de la satisfacció és la gran oblidada en els quadres de comandament dels Scrum Masters. Potser és l’indicador més important. Client feliç, equip feliç. Hi ha diverses formes complementàries d’esbrinar la satisfacció de totes les parts, però la més efectiva és situar inputs en la Sprint Review (i posteriorment).
No oblidem que la satisfacció mai és exclusiva dels usuaris. Són importants, però no són els únics. La satisfacció també és objecte de desig de l’equip. Tenim una oportunitat cíclica d’avaluar la satisfacció amb l’equip. La Retrospectiva.
L’efectivitat consisteix a adquirir la consciència necessària que, serem efectius en el moment en què assolim els objectius establerts (eficàcia) amb la maximització dels recursos i eines disponibles (eficiència). El món no funciona sent únicament eficaços o únicament eficients. S’ha de trobar un equilibri entre aquests dos factors. Això és l’efectivitat.
