Scrum metrics: when to use?

Metrics are numbers, figures; they cannot represent reality….but they could be triggers that help in taking decisions.

---

Metrics, in software development, are usually requested by managers that want to know about the teams’ performance.

Agile teams usually know very well about their performance and the quality they are putting in. They also know quite well what’s the magic formula, that is different for every team, to balance  effectively perfomance and quality.

One day it happens, though, that pressure starts to grow.
The ProductOwner asks for some more functionalities, usually because of some changes about new ‘absurd’ deadlines. Obviously, the team tries to find different solutions or compromises engaging both the ProductOwner and the management people, but business is business they say.

The team struggles in balancing the requested increased level of performance, with the high quality standards agile prescribes, whatever XP, Scrum, Kanban or any other approach you are using. The healthy practices like pair programming, test driven development, refactoring, code inspection are slowly but progressively put apart.
This situation is disruptive for quality as well as for the team.

 

But, what I’ve noticed is that providing the right metrics to the management, could be the key factor that helps teams to face the situations like the one just mentioned.
Let’s see how.

First: your metrics obviously will report performance data like the velocity (user story points finished within each iteration).

Then, remember to associate to the velocity, also the metric ‘remaining story points’ (story points related to stories not finished within the sprint); that’s a metric that can mean at least two major things:

1. The team wronlgy selected too much stories (e.g. due to estimation errors)
2. The team was forced to select (consciously or unconsciously) too much stories (e.g. the CEO decide a new deadline and the PO pushes for more stories)

Usually, if the problem is how the team makes the estimations, this number will decrease progressively the next iterations, until it will reach zero.
When, on the other side, the PO and/or the managers push for releasing more stories, that number won’t decrease. This situation is also witnessed by other qualitative indicators.

 

Gather other qualitative information like the coverage of the unit tests, the # of test successfull/failed, # of issues closed vs new ones, # of broken builds, can help to study the qualitative trend of the product.

This data should be automatically collected by continuous building and integration systems and, again, automatically aggregated in database, in order to let the team remain completely focused on the development.

Once I have that data, I usually create two different graphs: the radar and the line graph.

 

The radar graph represents the results of each sprint, joining together different indexes. This kind of graph, actually, gives also a visual representation of the covered area: the larger, the better. The line graph helps to see what’s the underway trend of quality, verifying for example if some corrective actions done in the past, have brought any results.

Hence, let’s first concentrate on the radar graph. What I make is to transform the data just collected (see above), in qualitative indexes (e.g. from 1 to 5: 1 poor…5 excellent). Then, I calculate a Quality Index (QI), which is simply the sum of each index.

I’m not yet satisfied.

 

I do not want to assign the same weights to all indexes. Indexes like the # of tests sucessfull and  the coverage of the unit test or, furthermore, the # of broken build, must have different weights.

The successfulness of tests are something that I assume is somehow taken for granted. When a developer writes a unit test, I assume that she writes the code correctly.
Talking, instead, of indexes such as the broken builds or the coverage, I consider them much more important, because break a build or have a low unit test coverage, is something really bad.

This is the reason why I assign weights to the metrics I’m studying, like the ones below reported.

Now it’s time to recalculate the indexes according to the weights just assigned to each.

And finally, my graphs magically appear!

Here it is the radar graph where every axes represent an index.

The line trend graph is displying the QI, that is the sum of all the weighted indexes.

Remember, metrics are numbers.

Do not rely only on them when it’s time to take decisions: use this data to prove and certificate your feelings, impressions.

 Often your gut feeling is better than any metric!

Have fun

The SWOT: an innovative tool for agile retrospective

Yes, of course I’m joking, the SWOT analysis isn’t an innovative tool, but have you ever use it for analysing how an iteration has gone?

---

Hi there, holidays are over and a new working year is ready to start!
During my vacations I read a lot about agile retrospectives and it was an opportunity to compare the techniques and the tools mentioned in those books, with the ones I use in my everyday working life.

What actually I did not found is one of my preferred tool: the SWOT analysis.
That tecnique is so versatile that can be adapted easily. It was born to be used mostly for conducting marketing activities to devise new products.
On the other side, that of the traditional project management approach, it was applied to the projects in order to conduct the risk identification phase.

Actually, I use that technique at least in two other occasions.

Firstly, when I want to stimulate and accompanying the growth process mine and of my colleagues and team members. I help them to identify, related to their job and daily working activities, what are their strenghts and weaknesses in order to understand which opportunities could be developed and to what weaknesses they are exposed to.
Secondly, it is a fantastic tool to conduct a retrospective meeting. How? Let’s go!

As the major part of you already know, an agile retroscpective meeting is a meeting that usually lasts 4 hours, which is held at the end of a sprint (iteration), just immediately after the team has shown what it was developed (demo meeting).

The scope of this meeting is to reflect about what was good and what was bad about the last iteration. Considering the necessity to help people to actively participate and freely express opinions, ideas and any doubts, it’s better (read as mandatory) if that meeting is opened only to the the team, the scrum master, and the product owner (but only as a spectator).

Once the environment is ok and the meeting is open, distribute to the participants the SWOT matrix template and ask to each to address their thoughts on the iteration just concluded.
The focus is on the tools and techniques used, the approaches and behaviours kept by the people involved, the things happened during the iteration.
It is mandatory to absolutely avoid any direct reference to collegues, rather indicate the behaviour that should be rewarded or penalized, never cite an individual.
Remember that it is not a matter of finding the guilty, it’s a matter of improve performance and why not, to work better with sustainable paces.

Compile

The first quadrant contains the strenghts: which attitudes, behaviours, approaches were good. What, in the end, shall be reiterated to actually continuing to bring real worth to the project.

The second quadrant is a container of weaknesses (please do not confuse it as a garbage bin, there’s much to learn from our weaknesses): think of what has gone in the wrong way and analyze what is missing and where the problems were.
Think about the bad effect that was caused by the problem and try to conduct an analysis in order to climb to the root reason.

Now it’s time to concentrate on what could be exploited and what should be avoided: respectively the opportunities and threats quadrants.
The opportunities quadrant should comprise a list of “good things/objectives” the team/project/sprint could reach in case of investing in improving the strengths or bridging the weaknesses above reported. If possible connect each opportunities or threats to the relative strenght or weakness.

On the contrary the threats quadrant is reserved to the consequences that could arise in case no improvement is put in place.

Arrange

When every team member has finished to compile the “SWOT”, it’s time for each of them to write on a white-board, flip-charts or sticky notes both the strengths (good things) and weaknesses (bad things) giving insights regarding the opportunities and threats that they can bring aboard.

When finished, the agile retrospective leader (role that should be assigned in rotation to every team member), tries to identify which items are duplicate, eliminate them and  the remaining are grouped, clustering them under a category, a word, a statement that clearly explains them.
Now you have a well arranged situation of what has been the iteration just finished, in terms of good and bad things: solicit the team to devise and propose activities that aim to solve problems and enhance the performance according to what above reported.

Vote

And, finally, it’s time to vote: do you know DotVoting?
Simply assign a predefined number of votes to each team member that he can distribute on the activities.
Everyone can assign one vote for each desired item or assign all the dots/votes to one item, if they feel that is an important one.

Arrange the result as a bar graph (do you remember pareto and the 80/20 rule?) and pick the most voted activities, those must be executed during the course of the next sprint.

Final Considerations

• Do not put into the pipeline too many activities for the next iteration; most of the time it is better to process one at a time.
• Try to focus on the strenghts instead of weaknesses.
  Try to maximize the benefits coming from what the people can do better: their talents and qualities.
  It is more difficult to work on weaknesses.
  Obviously, if the weakness has an heavy and bad impact on the team/project/sprint, do not hesitate to deal with it.
• Everyone during the meeting should actively participate: your responsibility as a Scrum Master is to go along with the retrospective leader and stimulate who is not actively participating or try to contain who tends to speak to much or has a coercitive approach.
• Keep in mind these three words: APDC, CPI, Kaizen. They teach us to continue to improve the process, even a small adjustment can lead to great improvements.

Articolo Progetti e Qualità

Pubblico un mio articolo apparso sulla rivista DeQualitate di ottobre, in cui parlo dei diversi macro-aspetti che riguardano i progetti e la qualità.

Progetti e qualità

Quali sono le dimensioni della qualità in un progetto? In che modo la qualità aumenta le possibilità di successo? Chi sono le persone maggiormente coinvolte nell’assicurazione della qualità di progetto?

---

Quando si parla di qualità in riferimento ad un progetto, si può cadere nell’errore di valutarla solo in capo al prodotto o servizio rilasciato in produzione.

Dal punto di vista del committente, infatti, il focus è indirizzato sul risultato finale.

Le sue richieste saranno quelle di avere in tempi brevi prodotti con ottime performance, buona usabilità, look & feel accattivanti e, possibilmente, con zero difetti.

L’azienda che ha in carico la commessa, invece, dovrebbe considerare della qualità, anche tutti quegli altri aspetti legati ai processi coinvolti nell’esecuzione del progetto, al loro miglioramento continuo, alla comunicazione, alla cultura e alla formazione.

Quanto sopra è ancora più avvalorato dal fatto che la contrazione economica che i mercati oggi stanno vivendo e la conseguente riorganizzazione strutturale, offrirà maggiori possibilità di sopravvivenza a chi, investendo nella qualità, avrà saputo tramutarla in arma competitiva e perché no, nel medio o lungo periodo, in opportunità concrete di maggiore profittabilità.

 

Deming ci insegna che nell’85% dei casi i problemi di scarsa qualità riscontrati nei prodotti, sono da imputarsi a problematiche di processo e non operative.

E’ quindi per questo che è necessario pianificare la qualità nei processi inerenti al progetto: otterremo risultati eccellenti a cascata anche sul prodotto finale.

Qualità nella comunicazione

A più riprese in questo blog ho parlato di quanto sia centrale la comunicazione nei progetti, sottolineando l’importanza della qualità della stessa (vedi Commitment e responsabilità, Comunicazione agile, Successfull Projects).

Volendo riassumere i punti salienti di una comunicazione di qualità, possiamo dire quanto segue:

• Comunicazione diretta con gli stakeholders di progetto
• Particolare attenzione ai messaggi non verbali del nostro messaggio (intonazione della voce, pause, postura) per dare maggiore enfasi e qualità allo stesso
• Verifica della corretta ricezione del nostro messaggio attraverso la richiesta esplicita di un feedback al nostro interlocutore
• In caso di assegnazione di attività e compiti, affiancare il messaggio verbale con strumenti di assegnazione delle responsabilità quali RACI e RAM Matrix

Cultura della qualità

I risultati non saranno mai completamente raggiungibili se il team, e di conseguenza l’azienda, non sarà perfettamente allineata sui concetti di base e sulle aspettative da raggiungere in termini di qualità.

Un aspetto fondamentale è, infatti, la definizione aziendale degli standard lavorativi e qualitativi, detti anche “ground rules” o norme di base.

Questi possono essere direttive, politiche aziendali, modalità, template, approcci oramai collaudati, da utilizzarsi durante lo svolgimento del progetto e comunque posti sotto processi continui di revisione e controllo.

Devono essere obbligatoriamente raccolti, esplicitati e ufficializzati in azienda e resi disponibili attraverso manuali e procedure, direttamente accessibili dai membri del team.

Infine, un lavoro importante che favorisce un potente incremento della qualità, deve essere svolto nei confronti delle persone che compongono il team, ponendo attenzione particolare alla loro crescita nell’utilizzo delle tecniche e degli strumenti disponibili.

La formazione rispetto a quei temi è centrale.

Quando questa, poi, viene direttamente fornita dal project manager o dai componenti più anziani del team sotto forma di sessioni di training-on-the-job, si ottiene anche un “effetto team building” che indirettamente produce maggiore coesione e senso di appartenenza al team stesso.

Il responsabile della qualità di progetto

Ovviamente il project manager è il primo e unico responsabile della qualità di progetto.

Già in fase di studio, ancora prima di essere incaricato, dovrebbe raccogliere informazioni su eventuali piani e politiche di qualità che l’azienda committente adotta internamente.

Quanto sopra ha due vantaggi.

Il primo è che queste informazioni sono vitali in fase di valutazione tempi/costi del progetto stesso: standard qualitativi molto elevati o ambiziosi potrebbero avere una ricaduta sostanziale sull’intero processo di stima.

Il secondo aspetto, se vogliamo più interessante, riguarda il fatto che il project manager grazie a quelle informazioni, potrà sin da subito cominciare a pianificare la qualità e sin da subito cablarla nel progetto.

E la qualità sul prodotto?

Finalmente il team potrà passare alla verifica della qualità anche sul prodotto.

Questi momenti di verifica dovranno essere stati pianificati e schedulati anticipatamente e dovranno avvenire utilizzando gli strumenti e le tecniche solitamente a disposizione quando si parla di project management:

• ispezioni
• test
• check list
• diagrammi causa-effetto
• carte di controllo
• grafici di pareto
• diagrammi scatter

Risk Management Checklist

Riprendiamo un argomento fondamentale per favorire il successo del progetto: la gestione dei rischi. In un precedente post ho descritto un possibile approccio alla definzione dei rischi, in questo post cercherò di evidenziare aclune aree da indagare per abbatterli.

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Successfull Projects

In questo post cercherò di identificare le principali cause fallimento dei progetti cercando di trovarne un denominatore comune.

Questo post è disponibile ai soli utenti registrati.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users. Please register using the side-bar on the right.

Revisione dei processi di project management

Come possiamo migliorare la qualità dei nostri processi di project management?

 

Qualche giorno fà ho partecipato ad una sessione di brain-storming organizzata da un cliente, che aveva come unico scopo: quello di focalizzare l’attenzione sui processi di project management utilizzati nell’anno appena passato.

Inzialmente fui piuttosto sorpreso, credevo infatti che la riunione fosse stata organizzata per mettere in risalto eventuali nostri difetti come fornitori e avevo preparato armatura, scudo e…scuse.

Nella sessione, invece, si sono analizzati i problemi riscontrati nella gestione dei progetti passati, indifferentemente dalla parte in causa.

A questo incontro hanno fatto seguito: una mappa mentale dell’incontro con le segnalazioni suddivise tra cliente e fornitore e un documento in cui si invitava ogni partecipante a fornire almeno tre possibili soluzioni/migliorie alle singole tematiche.

In un post precedente, parlando di qualità, ho citato l’importanza del continuo miglioramento dei processi di project management e attività di questo tipo sono portatrici di grande valore.

Va però tenuta in grossa considerazione il fatto che approcci di questi tipo possono vedere la luce solo in presenza di questi due fattori:

• buona cultura di project management del cliente
• buona continuità di progetti con il cliente

Riguardo al primo punto, noi siamo caduti in piedi in quanto il collega e amico Bruno, vestiva in quell’occasione i panni di cliente e non di mio co-relatore ad un seminario sul project management.

Anche il secondo punto era soddisfatto in quanto con l’azienda cliente che lui rappresentava, esiste una continuità di lavoro piuttosto intensa.

 

Questa esperienza affianca e completa momenti simili che viviamo in azienda abbastanza regolarmente e che coinvolgono tutto il team.

Con buona cadenza, infatti, organizziamo meeting in cui ognuno porta idee, critiche costruttive, proposte, revisioni riguardanti uno di questi temi:

• framework di sviluppo applicativo proprietario
• metodologia di analisi del progetto e relativa documentazione
• strumenti di lavoro a supporto del team
• strumenti di comunicazione e condivisione delle informazioni
• qualità nel rapporto con il cliente
• crescita dei membri di progetto

Gli outcomes di questi meeting danno vita ad una serie di issues che vengono raccolte, catalogate e prioritizzate.

 

Poi, però, arriva la vera nota dolente.

Prendere la decisione di quando queste migliorie dovranno essere apportate.
Oggi ho sul mio tavolo, almeno due documenti di alcune pagine, riportanti segnalazioni di quel tipo e che aspettano da alcuni mesi di essere evase. Come spesso accade, le pressione del lavoro, le consegne e le relative scadenze, non permettono di implementare tali migliorie tutte in una sola soluzione.

Però per lo scopo, possiamo prendere in prestito la tecnica degli sprint dallo sviluppo agile.

• Si definisce un tempo in giorni: 2/3 gg massimo.
• Una volta prioritizzate le issues, insieme al team, si scelgono quali siano le più importanti.
• Queste poi vengono assegnate ai membri del team e si procede all’implementazione e alla messa in produzione dei risultati.

Questo approccio ha due vantaggi.

Il primo risiede nel fatto che un ritardo di due o tre giorni sui progetti running a causa dello sprint sopra, è facilmente recuperabile.

Il secondo si basa sul principio di Pareto che cita:

“La maggior parte degli effetti è dovuta ad un numero ristretto di cause.”

o ancora

“l’80% dei problemi è dovuto al 20% delle cause”

Quindi, avendo a monte prioritizzato le problematiche e scelto per prime quelle in assoluto più importanti, dovremmo aver sensibilmente ridotto i problemi a carico di strumenti, metodologie e approcci.

Continuous Process Improvement

L’attenzione alla qualità in un progetto, è quella caratteristica che può far scegliere noi rispetto a un competitor. E un insieme di attenzioni, processi, considerazioni, ripensamenti se necessario o più semplicemente un processo di continua tendenza al miglioramento, spesso figlio della passione per il nostro lavoro.

 

Governare un progetto non significa solo avere a che fare con pianificazioni, stime, budget, rischi o attività di team bulding.

La gestione della qualità è un argomento spesso sottovalutato e tenuto in scarsa considerazione. 

Una frase molto in voga per chi è del mestiere  è “Quality should be planned in not inspected in”: la qualità dovrebbe essere pianificata, prima ancora di essere ispezionata.

Quando ho letto per la prima volta la sezione del gruppo di processi di qualità del PMBOK, sono rimasto colpito dal numero di volte con cui erano citate le parole “continuo miglioramento dei processi” oppure “processo di continuo miglioramento”.

La prima citazione la elevava a pilastro portante dell’intera disciplina della gestione della qualità, citando la sua appartemenza a standard come TQM (date un occhio al punto sei di wikipedia del link precedente) o Six Sigma.

Successivamente è indicato come processo iterativo condotto come attività pianificata durante l’esecuzione del progetto.

Poi si passa a considerarlo come evento, attitudine, predisposizione preferibilmente a cadenza naturale da parte di tutti i team member.

Infine viene citato come possibile causa di richieste di cambiamento al progetto: la revisione dei processi, delle metodologie di progetto, potrebbero imporre necessità di aggiustamenti o revisioni al progetto stesso e quindi alcuni, a torto, potrebbero considerarlo con negatività.

La mia esperienza mi insegna il contrario.

Questa è un’attività fondamentale e affascinante; spinge ciascun elemento del team a superare se stessi, è la sfida dentro alla sfida, l’eccellenza non fine a se stessa ma come strumento di miglioramento continuo del nostro operato.

Questa attività unita ad un coordinamento effettivo e pragmatico della qualità, porta senza dubbio alcuno ad una riduzione dei guasti/bugs, ad un incremento del livello minimo di  efficienza e efficacia e spesso all’identificazione di attività inutili o a nessun valore aggiunto per il progetto.

 

Il trucco non è fare tante cose fatte male.
Neanche farne poche fatte bene.
Il trucco è farne tante, fatte bene; per arrivarci però è necessario passare da entrambe le precedenti.