Scrum funciona perquè proposa una sèrie d’activitats que cal executar d’una manera determinada. Aquí explicarem com, qui, quan i perquè es fan aquestes activitats.
La base de totes les activitats de Scrum és el Sprint. El Sprint és la peça a partir de la qual organitzarem la feina en un marc de treball que afavoreixi la focalització, l’atenció a la qualitat i al lliurament de valor de forma continuada.
El Sprint és el temps que l’equip atorga per la construcció d’una petita part del producte. Prou petita per a què sigui perfectament entenible per l’equip i no superi l’horitzó de previsió. I prou gran per a proporcionar un increment de valor per als destinataris del producte.
El Sprint, a més es pot veure des d’una altra perspectiva. Com un gran contenidor. L’equip troba pautades totes les activitats necessàries per tal d’assolir l’objectiu de lliurar un increment de valor en finalitzar el Sprint. Hi ha tres activitats àmpliament conegudes i clarament visibles a cada Sprint:
Aquestes activitats es caracteritzen per executar-se una sola vegada a cada Sprint. Però a més, hi ha dues activitats més que es duen a terme al llarg del Sprint i que s’executen diverses vegades al llarg del mateix:
Al llarg d’aquest article explicarem cada una d’aquestes activitats.
L’horitzó de previsió correspon a un dels principis essencials de la teoria de control de processos empírics (empirisme) que, recordem, és la pedra filosofal del marc de treball Scrum. L’horitzó de previsió diu que hi ha un moment en el futur en que, si ocorre un fet inesperat, aquest pot tenir repercussions negatives sobre la feina que estem fent ara.
Aquest horitzó no convé superar-ho si volem fomentar equips que puguin focalitzar-se en la creació d’increments de valor de forma iterativa. I es mesura en setmanes (mai en mesos). És per això que Scrum basa la durada del Sprint en una forquilla de temps que va d'1 a 4 setmanes. Scrum afirma que un canvi no és més que més feina al Backlog. Això només és possible si treballem en iteracions de temps que permetin tenir control de l’horitzó de previsió.
Un MVP (Minimum Valuable Product o Minimum Viable Product) és la peça mínima objectiu d’un Sprint. Quan parlem que el Sprint afavoreix la creació d’un increment de valor ens referim al fet que aquest increment ha de proporcionar un benefici tangible als destinataris del producte. Nosaltres, com a equip, i juntament amb els destinataris del producte adquirim un compromís bidireccional:
No pot haver-hi una cosa sense l’altre. No pot haver-hi valor si els destinataris no ens donen feedback. No pot haver-hi ús si l’equip no és capaç de proporcionar valor.
Però, que és “increment de valor”?
L’esquema següent intenta donar una explicació:
| Increment | Valor | |
|---|---|---|
 |
 |
A la primera il·lustració tenim un exemple de producte incremental, que té com a objectiu la construcció d’un vehicle. Per a fer realitat aquest propòsit últim, es proposa una política d’increments consistent en proporcionar “peces” del vehicle perfectament funcionals. Així es planteja proporcionar en primera instància les rodes, posteriorment el xassís, la carrosseria i, finalment, el desitjat vehicle.
La pregunta que segurament molts us esteu fent és: Quina utilitat té per al destinatari d’aquest vehicle que li proporcionem les rodes? Per molt perfectes que siguin. Per molt que acompleixin els criteris de qualitat més exigents, ningú fa res específic amb unes rodes. Aquest és un exemple de què podem lliurar un producte en períodes iteratius, però no per aquest motiu serem àgils. L’agilitat ha de preveure altres factors necessaris. I un de molt important és el valor continu (MVP)
Al segon exemple podem veure que l’estratègia és diferent. Per tal de proporcionar aquest vehicle últim, es proporcionen parts intermèdies que, per si soles resolen alguna necessitat específica. Suposo que algú deu estar pensant. Si ok!! Però això té un preu!! Sembla que requereix més esforç aquesta última estratègia respecte a la primera. És cert. Requereix esforç per part de tothom:
A vegades no és possible donar valor en finalitzar un Sprint. Bé sigui perquè el sprint és molt curt. O perquè provoca moltes molèsties en un producte que pot ser crític. O perquè operativament és molt difícil fer la publicació dels increments a cada Sprint. Sigui com sigui, hi ha ocasions en què el Scrum Team pot pactar una política de releases. La release no és més que la suma del valor de diversos Sprints.
Aquesta política és variable i es pot sotmetre a canvis o a la conveniència de l’equip o de l’organització. Així, en un projecte, es pot establir una release dels sprints 1 i 2, posteriorment una release del sprint 3, per acabar amb una release dels sprints 4, 5 i 6. Qualsevol combinació seria vàlida sempre que sigui producte del consens del Scrum Team.
La Release no pot servir de justificació per alterar qualsevol de les activitats de Scrum. Si en un Sprint no es publicarà el valor obtingut, no treu per a què el Sprint Review s’hagi de fer de forma completa i amb la participació del Product Owner i dels Stakeholders.
(+info Sprint Planning. Detalls que cal conèixer)
El Sprint Planning és la primera activitat que cal executar sempre a l’inici de cada Sprint. El Sprint Planning té com a objectiu organitzar el treball per aquell Sprint. Permet als tècnics focalitzar-se en un objectiu petit, assumible tècnica i organitzativament, i de valor. Per assolir aquest objectiu l’equip disposa de 8 hores de temps per a sprints de 4 setmanes.
A aquesta activitat hi assisteixen el Product Owner, l’equip tècnic i el Scrum Master. La reunió ha de ser liderada per l’equip tècnic, el qual es compromet a disposar de la informació i a haver treballat els temes necessaris per poder executar aquesta activitat de forma efectiva. Això implica forçosament que l’equip, durant el Sprint anterior, ha d’haver treballat de forma completa almenys totes les històries d’usuari més prioritàries.
(+info Sprint Review. Detalls que cal conèixer)
Un cop el Sprint arriba a la seva última jornada. Arriba el moment de sotmetre a inspecció el resultat de la nostra feina. El Sprint Review és el moment de mostrar l’increment, i demostrar el seu valor i la seva qualitat. Directament als destinataris del producte (sense intermediaris).
El Sprint Review és la reunió més coral de totes les existents. Té una durada màxima de 4 hores per a sprints de 4 setmanes Temps més que suficient per poder mostrar l’increment construït. Aquesta reunió està liderada pel Product Owner. I hi ha d’assistir tothom. Especialment, una part prou representativa dels destinataris del producte (els stakeholders més impactats per l’increment). El Product Owner no pot exercir de Stakeholder en aquesta reunió. Alguns dels tècnics i el Scrum Master també han d’assistir.
No es tracta de fer una demo. I no es tracta de fer una acceptació amb dades maquillades. Es tracta de què els stakeholders toquin el producte en un entorn realista i comprovin els criteris d’acceptació que permetin donar una acceptació ferma.
El Product Owner que porta l’agenda de la reunió, i convida a les persones que cregui convenient
(+info Sprint Retrospective. Detalls que cal conèixer)
La Sprint Retrospective és l’activitat específicament dissenyada per a què l’equip tingui un espai per la cerca de la millora continua. La millora contínua es duu a terme des de múltiples perspectives:
El concepte de millora contínua guarda relació amb la teoria de control de processos empírics, i va ser definit per primera vegada als anys 50 per Edwuards W Deming, amb el que es coneix com a cicle de Deming o PDCA
El cicle de Deming proposa que, si volem millorar qualsevol aspecte de la nostra feina, hem d’afegir dues accions a les ja conegudes de “Planificar” i “Executar”. Si només planifiquem i executem no tenim espais ni motius per trobar aspectes de millora sobre el que hem fet. Així Deming planteja dues accions noves:
En Scrum, l’activitat del Sprint Review permet realitzar aquesta tasca d’inspecció. I l’activitat de Retrospectiva permet cercar i planificar les accions d’adaptació que permetran millorar a les iteracions següents.
Una retrospectiva centrada en els problemes no és una bona retrospectiva. Cal generar entorn de grup i motivació. I és per això que els èxits s’han de celerar sempre.
El Scrum Master és el responsable d’organitzar la reunió i crear la dinàmica per tal d’extreure aspectes de millora útils per a l’equip.
Una llista de propostes o d’accions. De les quals ha d’existir el compromís d’aplicar alguna d’aquestes millores al sprint següent. No existeix millora contínua sense feina. O dit d’una altra manera: Al Sprint següent han d’existir accions tangibles centrades en l’aplicació de petites millores. Aquestes accions poden ser de naturalesa molt diversa:
etc.
Curiosament, immediatament després d’una retrospectiva no s’inicia un nou sprint. Generalment, hi ha unes hores mortes que poden tenir utilitats molt profitoses:
(+info La Daily. Detalls que cal conèixer)
La Daily és una reunió diària i ràpida que permet la sincronització dels tècnics que participen en el projecte. És una reunió necessària que, si es fa correctament, marcarà un abans i un després en la relació amb i entre els tècnics. Després de molts anys de treball seqüencial i reactiu, és habitual trobar que els tècnics tenen problemes a l’hora de comunicar-se amb els seus companys. S’estableix un mecanisme d’encàrrec que provoca que els tècnics es centrin en la seva feina particular, i no es preocupin per la integració i la sincronització amb la feina de la resta de l’equip. Podria dir-se que s’ha afavorit durant anys que la gent es tanqui a la seva cova particular.
La Daily pretén ajudar a resoldre això i a fomentar el veritable compromís de l’equip, per sobre de la simple implicació. Per assolir això es proposa que els tècnics, diàriament, comparteixin la situació de la seva feina, i col·laborin per avançar en un objectiu comú: Proporcionar valor a terminis curts de temps.
Els tècnics. I únicament ells en favor del poder auto-organitzatiu que ostenten. El Scrum Master pot assistir a les Dailys de forma voluntària. El Product Owner i els Stakeholders estranyament tindran motius per assistir a una Daily.
Usualment, les reunions de Daily es duen a terme al principi de la jornada laboral. Per tal que els tècnics puguin sincronitzar-se i seguir amb la seva jornada amb informació actualitzada.
(+info Refinement. Detalls que cal conèixer)
El Refinement és potser l’activitat més desconeguda en Scrum. No té una única motivació. I serveix per a fer tot allò que no faríem en qualsevol altra reunió de les descrites anteriorment. La durada també és variable. Existeix una recomanació de què una reunió de refinement no superi 1 hora de durada. Sempre que sigui possible, seguim aquest consell, ja que l’atenció dels assistents a la reunió disminueix molt passada la primera hora.
Per altra banda, es recomana no fer reunions de refinement per un temps global que superi el 10% de la durada del Sprint. Es a dir, per a jornades tradicionals de 8 hores diàries i sprints de 15 dies, no hauríem de superar una durada global de reunions de Refinement per sobre de les 8 hores. Si superem aquest límit probablement estem afectant la normal execució del Sprint. I estaríem comprometent els objectius del Sprint.
Com que la motivació no és clara, no existeix un únic responsable de la reunió. La responsabilitat la tindrà la persona amb major interès per a què la reunió tingui lloc.
Molt important mantenir sempre el Product Backlog actualitzat amb els canvis o nova informació que hem obtingut a la reunió.
(+info Mapa d’activitats Scrum)
Habitualment penjo aquest diagrama als taulers físics, o bé als repositoris de treball, per tal que tot l’equip sigui coneixedor de les activitats, objectius, responsables i tempos que tothom en el projecte hauria de conèixer. Això no substitueix les múltiples accions de formació i foment que com a Scrum Master sempre hauríem de tenir a la nostra agenda. Però ajuda força que l’equip tingui accés a aquests esquemes.
Descarrega l’esquema per imprimir aquí
