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!

In my Certified Scrum Master training in Atlanta with Jeff Sutherland last week we did a few very cool exercises. The one that proved its intended point the best was the Scrum Penny Game. This game is actually an exercise created partly by Joe Little. This activity really illustrates the benefit of developing in small iterations.


The Setup

To run the exercise you need 20 pennies, 6 stopwatches, and 10 people. Sit 5 people around a table. Assign 4 of them as workers for department 1 thru 4. The last person sitting at the table is the customer. The other five people will stand behind one of the people seated at the table. The people standing behind the workers are the department managers. The person standing behind the customer is the company president. All of the people standing have stopwatches as well as the customer. Place the 20 pennies heads up in front of department 1.





Running the Exercise (First and Second Pass)

You will run the exercise 6 times. The first pass starts with the worker in department 1 turning over each penny in front of them with one hand from heads to tails. As soon as the worker starts, the manager for department 1 starts his stopwatch as do the customer and the president.

When all the pennies have been turned over to tails, worker 1 will slide over all 20 pennies to the worker in department 2 next to them. When the first penny is moved to worker 2, manager 2 will start their stopwatch. When the last penny is moved from worker 1 to worker 2, manager 2 will stop their stopwatch. This process will be repeated for worker 2, worker 3, and worker 4.

When the first penny is moved to the customer from worker 4, the customer will stop their stopwatch. When the last penny is moved to the customer from worker 4, the president will stop their stopwatch.

Record the results of the first pass in a table like the one below:

This chart shows each departments productivity, the time to market (the first penny to the customer), and project completion (the last penny to the customer).

Perform the second pass exactly as you did the first pass. Make sure before you start all the participants with stopwatches reset them. Record the second pass results on your chart.

Running the Exercise (Third thru Sixth Pass)

On the third pass each worker will pass 10 pennies at a time to the next in line. So once worker 1 has turned over 10 pennies, they will pass them to worker 2 who can then start turning over their pennies while worker 1 turns over their remaining 10. It will not be more important that the customer stop when the first batch of 10 pennies arrives and the president stops when the last batch arrives. Record your results in your chart.

The fourth pass the batch size is decreased to 5 and the fifth/sixth pass the batch size will be 1 penny. Record both passes results.

The Results

At the end of the exercise review the results with the team and you will see some very interesting trends. The chart above is the results from our exercise at the Scrum training.

• When the team repeats the process with the same batch size they generally increase individual and overall productivity.
  


• As the batch size decreases each department’s individual productivity decreases.
  


• As the batch size decreases, the time to market is faster.
  


• As the batch size decreases, the time to complete the entire project decreases.

I found that paradox that the smaller the batch size (or iteration), the worse each department’s individual productivity. As we discussed this we talked about how this illustrated how in Scrum each iteration encompasses all the activities of the SDLC making each individual effort a bit less productive. The other interesting point was how the overall productivity of the “company” was increased. We as a company were quicker to market and completed faster. It really brought home the point of small iterations of work to the entire class.

I have described the exercise to several clients that I am helping adopt Scrum and Team Foundation Server and they have all suggested that it should be something I have each client’s team perform to help them grasp the benefits of the iterative style of development in Scrum.

This week I attended a Certified Scrum Master course in Atlanta led by Jeff Sutherland and Joe Little. It was a great opportunity to hear best practices from the man himself. It was also great to be around a good group of people in different stages of adopting Scrum and we had some really great conversations.

Me with Jeff Sutherland in Atlanta.

For my first post on the training I wanted to describe how the course itself was run. One of the interesting approaches was that the training was run like a Scrum project. Each day Jeff populated our Sprint Task Board with subjects we would cover that day. Each hour he would move the cards on the board and update a burn down chart. All of the exercises were time boxed and he kept things going with Tibetan meditation bells to end a session.

The course manual had quite a bit of content and we did not make it all the way through the book. Jeff skipped around quite a bit and his slide deck had updated content that was not in the book but was provided to us afterwards. A good bit of content came from Henrik Kniberg's Scrum and XP from the Trenches book which I reviewed in my last blog post.

Jeff had many anecdotes of adopting Scrum from his many years of experience that made the ideas behind it a bit more real. There was a lot less rhetoric than I had anticipated and he backed up all the ideas with hard numbers from a multitude of studies. These numbers are great fodder for conversations with management when trying to convince them to adopt Scrum.

There were also some very cool activities that really illustrated the contrasts between traditional practices and those prescribed with Scrum. There are many paradoxes in Scrum (and Agile/lean processes) that produce results that are contradictory of what most people would think. I plan to post more info on some of these activities soon.

All in all it was a great class where I not only had a good bit of what I have been doing for that past couple of years validated but learned many new things as well. I would strongly suggest that if your company plans to implement Scrum that everyone involved in software development attend a training course of this type. Jeff recounted studies that have shown Scrum teams starting without a Scrum Coach or the right training normally only see about a 35% benefit initially where teams that are trained and coached well see a 400% increase in productivity.

Thanks to Jeff and Joe for a great course!