nokia-test-RANK

Quanto è Agile il tuo team? Il Nokia Test

Sviluppato da Bas Vodde e successivamente ampliato da Jeff Shuterland, il Nokia Test è usato per verificare la Agile Maturity di uno o più team.

Esistono diverse versioni del test. Quella che ti sto proponendo consiste di nove domande e relativo sistema di ranking. Le domande 1-3 riguardano gli aspetti fondamentali ed eventuali punteggi bassi in quest’area dovrebbero essere esaminati con attenzione e corretti il prima possibile.

Il test è mirato all’agililtà complessiva, e include quindi anche quelle practice (i.e. unit testing) che non sono direttamente/esclusivamente legate a Scrum. Il test può inoltre essere ulteriormente contestualizzato per monitorare i processi specifici utilizzati in ogni organizzazione.

Il questionario e il ranking system

Riporto di seguito il questionario, che lo Scrum Master compila basandosi sullo scoring system.

Q1-Iterations
No iterations0
Iterations>6 weeks1
Variable lenght<6 weeks2
Fixed iterations lenght 6 weeks3
Fixed iterations lenghts 5 weeks4
Fixed iteration 4 week or less10
Q2-Testing within a sprint
No dedicated QA0
Unit tested1
Feature tested5
Features tested as soon as completed7
Software passes acceptance testing8
Software is deployed10
Q3-Enabling Specifications
No requirements – 00
Big requirements documents 1
Poor User stories4
Good Requirements5
Good User stories7
Just enough, just in time specifications8
Good User stories tied to specifications as needed 10
Q4-Product Owner
No Product Owner0
Product Owner who does not understand Scrum1
Product Owner who disrupts team2
Product Owner not involved with team2
Product Owner has a clear product backlog estimated by team before Sprint Planning meeting (READY)5
Product owner with release roadmap with dates based on team velocity8
Product owner who motivates team10
Q5-Product Backlog
No Product Backlog0
Multiple Product Backlogs1
Single Product Backlog3
Product Backlog has good uses sories that satisfy the INVEST criteria5
Two sprints of the product backlog are in a ready state7
Product roadmap is available and upated reguarly based on team estimiates of Product Backlog10
Q6-Estimates
Product backlog not estimated0
Estimates not produced by the team1
Estimates not produced by planning poker5
Estimates produced by planning poker by team8
Estimate error < 10%10
Q7-Burndown Chart
No burndown chart0
Burndown chart not updated by team1
Burndown chart in hours/days not accounting for work in progress (partial tasks burn down)2
Burndown chart only burns down when task in done (Track Done pattern)4
Burndown only burns down when story is done5
Add 3 points if team knows velocity
Add two point if Product Owner release plan
Q8-Team Disruption
Manager or Project Leader disrupts team0
Product Owner disrupts team1
Managers, Project Leaders or Team leaders telling people what to do3
Have Project Leader and Scrum roles5
No one disrupting team, only Scrum roles10
Question 9 – Team
Tasks assigned to individuals during Sprint Planning0
Team members do not have any overlap in their area of expertise0
No emergent leadership – one or more team members designated as a directive authority1
Team does not have the necessary competency2
Team commits collectively to Sprint goal and backlog7
Team members collectively fight impediments during the sprint9
Team is in hyperproductive state10

Visualizzazione dei risultati

I risultati possono essere visualizzati in un Radar Chart e condivisi tramite i consueti Information Radiatiors per essere poi discussi durante la retrospettiva.

Il radar qui riportato, ad esempio, mostra una criticità significativa nei processi di testing, con impatto potenziale sulla qualità del prodotto e sulla soddisfazione del cliente. Il team ha probabilmente bisogno di un training sulle pratiche agile per il testing, e successiva scelta e implementazione dei processi relativi. In fasi successive sarà possibile affrontare e risolvere anche le altre criticità emerse (es. disfunzionalità nei ruoli e nel funzionamento del team, etc.) in ottica di continous improvement.