Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A Parable of Why Agile Methods Can Save Money

DZone's Guide to

A Parable of Why Agile Methods Can Save Money

· Agile Zone
Free Resource

The Agile Zone is brought to you in partnership with Techtown Training. Understand how your role fits into your organization's DevOps transformation with our DevOps eBook.

Don Reinertsen gave a great keynote address at YOW 2012 entitled The Practical Science of Batch Size. I recommend watching the video when it’s posted, probably in January. In the mean time, I want to relate one small illustration from the talk. It’s a parable of why agile methods can save money.

Someone generates a two-digit number at random. You can pay $2 for a chance to guess the number, and if you are correct, you win $200. It’s a fair bet: both sides have net expected return zero.

Now let’s change the rules. Same reward, but now you pay $1 to guess the first digit and you find out whether you were right. If you were, you then have the option of spending another $1 to guess the second digit. Now you have a winning bet.

Your chances of winning are the same as before: there’s a 1% chance that you’ll win $200. But the cost of playing the game has gone down. There’s a 90% chance that you’ll spend $1 and a 10% chance you’ll spend $2. So your expected return is $2, but your expected cost is $1.10, so on average you make $0.90 every time you play the game.

Don argues that we often come out ahead by doing things in smaller batches: committing less money at a time, taking on smaller projects at a time, etc. Not that smaller batches are always better. As batch sizes decrease, holding costs decrease but transaction costs increase. You want to minimize the sum of holding costs and transaction costs. But we more often err on the side of making batches too large.

In the example above, the batch size is how much of the number we want to guess at one time: both digits or just one. By guessing the digits one at a time, we reduce our holding cost. And in this example, there are no transaction costs: you can guess half the digits for half the cost. But if there were some additional cost to playing the game — say you had to pay a tax to make a guess, the same tax whether you guess one or two digits — then it may or may not be optimal to guess the digits one at a time, depending on the size of the tax.

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap, brought to you in partnership with Techtown Training

Topics:

Published at DZone with permission of John Cook, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}