Recently I saw a brief set of questions from Nokia to assess whether or not a team is ‘agile’.
And by ‘agile’, I think they meant to what extent the team was following agile practices Scrum and XP (eXtreme Programming), not whether or not they could touch their toes π
I’m not sure if it was deliberately brief to emphasise the things that are the real *essence* of agile, but we’ve developed the questions into a more comprehensive set of statements. A set of statements that make a fuller assessment of someone’s status with agile principles and methods.
Here they are…
- The team is empowered to make decisions.
- The team is self-organising and does not rely on management to set and meet its goals.
- The team commits and takes responsibility for delivery and is prepared to help with any task that helps the team to achieve its goal.
- The team knows who the product owner is.
- Each sprint/iteration has a clear goal.
- All team members, including testers, are included in requirements workshops.
- Requirements documentation is barely sufficient and the team collaborates to clarify details as features are ready for development.
- Test cases are written up-front with the requirements/user story.
- There is a product backlog/feature list prioritised by business value.
- The product backlog has estimates created by the team.
- The team knows what their velocity is.
- Velocity is used to gauge how many user stories should be included in each sprint/iteration.
- Sprints/iterations are timeboxed to four weeks or less.
- Sprint budget is calculated to determine how many product backlog items/features can be included in the sprint/iteration.
- The sprint/iteration ends on the agreed end date.
- All tasks on the sprint backlog are broken down to a size that is less than one day.
- Requirements are expressed as user stories and written on a card.
- The team estimates using points which indicate the relative size of each feature on the product backlog/feature list.
- The team generates burndown charts to track progress daily.
- Software is tested and working at the end of each sprint/iteration.
- The team is not disrupted during the sprint/iteration.
- Changes are integrated throughout the sprint/iteration.
- Automated unit testing is implemented where appropriate.
- There is an automated build and regression test.
- Stretch tasks are identified for inclusion in the sprint/iteration if it goes better than expected.
- The Product Owner is actively involved throughout each sprint.
- All code changes are reversible and it is possible to make a release at any time.
- Testing is integrated throughout the lifecycle and starts on delivery of the first feature.
- Impediments that hold up progress are raised, recorded on the whiteboard and resolved in a timely fashion.
- When someone says ‘done’, they mean DONE! (ie shippable).
- The team uses the whiteboard to provide clear visibility of progress and issues on a daily basis.
- The sprint/iteration goal(s) is clearly visible on the board.
- All user stories and tasks are displayed on the whiteboard for the duration of the sprint/iteration.
- Daily scrums happen at the same time every day β even if the scrum master isnβt present.
- The daily scrum is resticted to answering the standard 3 scrum questions and lasts no more than 15 minutes.
- There is a product demonstration/sprint review meeting at the end of each sprint/iteration.
- All team members, including testers and Product Owner, are included in the sprint/iteration review.
- The sprint/iteration review is attended by executive stakeholders.
- There is a sprint retrospective at the end of each sprint/iteration.
- Key metrics are reviewed and captured during each sprint retrospective.
- All team members, including testers, are included in the sprint retrospective meeting.
- Actions from the sprint retrospective have a positive impact on the next sprint/iteration.
Our approach to these statements is this:
- Ask every team member of an agile team (including the product owner, tester, manager, everyone) to review the statements honestly.
- Ask them only to mark a score with a 1 if – and only if – they believe they are consistent and it could be audited. In other words, if I was to turn up at any time and ask for evidence, are you confident you could provide it. Otherwise score 0.
- Add up the 1’s for each team member. Then average the score for the team.
To what extent a team is really effective at all these points is another matter, of course.
But if a team has really got agile principles and practices consistently nailed, and according to every team member…
They score 42 of course! π
How agile are you?
Kelly.