Many Agile pundits think that you are either Scrum or you are not. I disagree with the concept that being Agile or Scrum is a bit flag. Some companies cannot (or will not) adopt all of the Scrum/XP practices initially. You can call them ScrumBut, Scrummerfall, or whatever, but these companies can (and do) still get value from adopting some of the practices of Scrum/XP. They will not get as much benefit and their gains will depend on what combination of process and practices they do adopt. True some of these combinations can actually be counter productive, but I do not think it is fair to shun anyone who is trying their best to implement them.
So when someone tells me they have adopted Scrum, I usually ask a handful of questions to see what they have adopted and to what extent. These questions mainly come from the Nokia Test and specifically the version Jeff Sutherland introduced at my Certified Scrum Master training.
The Nokia Test is to be taken with a grain of salt since it mainly measures the mechanisms you have adopted and only slightly gauges then intent (or ideals) behind them. I do think it is a decent, initial litmus test to see how far your implementation has gone. I have added a few sections to the test aimed at the complimentary XP practices I think are needed for a well rounded Scrum shop.
Here is my version of the test based on Jeff's 2008 version. Determine how many points you get for each question, add them together and then divide by 10.
Question 1: Iterations
- No iterations - 0
- Iterations > 6 weeks - 1
- Variable length <>
- Fixed iteration length 6 weeks - 3
- Fixed iteration length 5 weeks - 4
- Fixed iteration 4 weeks or less - 10
Question 2: Testing
- 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
Question 3: Specification
- No requirements - 0
- Big requirements documents - 1
- Poor user stories - 4
- Good requirements - 5
- Good user stories - 7
- Just enough specification - 8
- Good user stories tied to specifications as needed - 10
Question 4: Product Owner
- No Product Owner - 0
- Product Owner who doesn’t understand Scrum - 1
- Product Owner who disrupts team - 2
- Product Owner not involved with team - 2
- Product owner with clear product backlog estimated by team before Sprint Planning meeting - 5
- Product owner with release road map with dates based on team velocity - 8
- Product owner who motivates team -10
Question 5: Product Backlog
- No Product Backlog - 0
- Multiple Product Backlogs - 1
- Single Product Backlog - 3
- Product Backlog clearly specified and prioritized by ROI before Sprint Planning - 5
- Product Owner has release plan based on Product Backlog - 7
- Product Owner can measure ROI based on real revenue, cost per story point, or other metrics - 10
Question 6: Estimates
- Product Backlog not estimated - 0
- Estimates not produced by team - 1
- Estimates not produced by planning poker - 5
- Estimates produced by planning poker by team - 8
- Estimate error <>
Question 7: Burndown
- No burndown chart - 0
- Burndown chart not updated by team - 1
- Burndown chart in hours/days not accounting for work in progress - 2
- Burndown chart only burns down when task in done - 4
- Burndown only burns down when story is done - 5
- Add 3 points if team knows velocity
- Add 2 point if Product Owner release plan based on known velocity
Question 8: Team Management/Disruption
- External management disrupts team - 0
- Product Owner disrupts team - 1
- Product Owner or Scrum Master assigning tasks - 3
- Scrum Team assigns tasks - 5
- No outside disruptions, only Scrum roles - 10
Question 9: Build Automation
- No build automation - 0
- Continuous Integration build automated - 1
- Nightly build automated - 3
- Unit Tests run during nightly build - 5
- Feature tests run during nightly build - 7
- Deployment to other environments automated - 10
Question 10: Daily Scrum
- No Daily Scrum meeting - 0
- Daily Scrum meeting everyday - 1
- Daily Scrum meeting same time, place - 3
- Daily Scrum runs <>
- Add 2 if reported Impediments are logged
- Add 2 if tasks are directly updated during meeting
- Add 1 if only Scrum Team are allowed to speak
Keep in mind that Jeff told us his best client has a score around 8 and most shops score 6 or 7. I believe this shows that there is no perfect adoption and that all of us are working towards making our implementation better. My best client was around a 7 and it was a great shop to work in.
Let me know where your company lands and where you can improve!
4 comments:
Tommy, interesting take on the build automation piece. Why do I need a nightly build if I have a continuous build? Shouldn't I get more points for building more often, getting more communication out to the team, and raising visibility more?
I do agree that linking deployment automation is worth big points, and that more testing is better than less. But the more we can do all of those things, the better.
Anyway, I appreciate the post. I've been trying to take a careful look at the relationship between the build server and Scrum recently.
Eric,
CI is definitely very important, but most CI I see usually builds and runs unit tests. Our nightly builds generally build, run unit tests, deploy to an integration server, and run automated feature tests on the integration server. We have found this more valuable since it tests in a separate environment that more represents production ideally. And I have found automted feature testing finds more "bugs" than unit tests mainly because they are created by testers rather than the developer so they test more generally. Of course this is based on how my clients have implemented testing and automated builds so it is only one scenario.
What would you change with the point allocation?
Hi Tommy,
I just want to inform you that I took your slogan "Scrum How Are You?" to design my mug. See Mug "How Scrum Are You?". Regards, Fabrice
Fabrice,
That is wicked awesome!
Post a Comment