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 iterations | 0 | |
| Iterations>6 weeks | 1 | |
| Variable lenght<6 weeks | 2 | |
| Fixed iterations lenght 6 weeks | 3 | |
| Fixed iterations lenghts 5 weeks | 4 | |
| Fixed iteration 4 week or less | 10 | |
| Q2-Testing within a sprint | ||
| No dedicated QA | 0 | |
| Unit tested | 1 | |
| Feature tested | 5 | |
| Features tested as soon as completed | 7 | |
| Software passes acceptance testing | 8 | |
| Software is deployed | 10 | |
| Q3-Enabling Specifications | ||
| No requirements – 0 | 0 | |
| Big requirements documents | 1 | |
| Poor User stories | 4 | |
| Good Requirements | 5 | |
| Good User stories | 7 | |
| Just enough, just in time specifications | 8 | |
| Good User stories tied to specifications as needed | 10 | |
| Q4-Product Owner | ||
| No Product Owner | 0 | |
| Product Owner who does not understand Scrum | 1 | |
| Product Owner who disrupts team | 2 | |
| Product Owner not involved with team | 2 | |
| 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 velocity | 8 | |
| Product owner who motivates team | 10 | |
| Q5-Product Backlog | ||
| No Product Backlog | 0 | |
| Multiple Product Backlogs | 1 | |
| Single Product Backlog | 3 | |
| Product Backlog has good uses sories that satisfy the INVEST criteria | 5 | |
| Two sprints of the product backlog are in a ready state | 7 | |
| Product roadmap is available and upated reguarly based on team estimiates of Product Backlog | 10 | |
| Q6-Estimates | ||
| Product backlog not estimated | 0 | |
| Estimates not produced by the team | 1 | |
| Estimates not produced by planning poker | 5 | |
| Estimates produced by planning poker by team | 8 | |
| Estimate error < 10% | 10 | |
| Q7-Burndown Chart | ||
| No burndown chart | 0 | |
| Burndown chart not updated by team | 1 | |
| 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 done | 5 | |
| Add 3 points if team knows velocity | ||
| Add two point if Product Owner release plan | ||
| Q8-Team Disruption | ||
| Manager or Project Leader disrupts team | 0 | |
| Product Owner disrupts team | 1 | |
| Managers, Project Leaders or Team leaders telling people what to do | 3 | |
| Have Project Leader and Scrum roles | 5 | |
| No one disrupting team, only Scrum roles | 10 | |
| Question 9 – Team | ||
| Tasks assigned to individuals during Sprint Planning | 0 | |
| Team members do not have any overlap in their area of expertise | 0 | |
| No emergent leadership – one or more team members designated as a directive authority | 1 | |
| Team does not have the necessary competency | 2 | |
| Team commits collectively to Sprint goal and backlog | 7 | |
| Team members collectively fight impediments during the sprint | 9 | |
| Team is in hyperproductive state | 10 |
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.