Sunday, June 15, 2008

agile implementation versus releases

I've noticed this conversation coming up more frequently lately - business customers and even IT managers stating their desire to have IT development groups schedule software releases every so many months. They state this as a preference over what I call "implementation as completed" (similar to agile's short development cycles, but more flexible). Note that I am talking about development and enhancement of internal applications, not software for sale.

I've stated my disagreement with this direction. I've won some people over, some not. It seems so clear to me, but either I'm not communicating my argument very well, or it is a difficult concept to grasp. Maybe putting my argument in writing will help. So here goes:

I have 3 arguments for implementing functionality as it is completed:

  1. You have more flexibility in adapting to changing priorities. The people I'm talking about want to have an up-front process for selecting functionality to be included in the next release; and then have that functionality made available on the release date. The problem with this is that it locks you into that specification. Sure, you can change the scope after the work has begun, but that requires negotiations, reestimation of the work and time required, and possibly re-work. In contrast, my preferred method is to maintain a prioritized list of desired functionality, and to work on these requirements in prioritized order. If priorities change, you either lose only the time put into the current task, or you only have to wait for the current task to complete before the new highest-priority task is begun.

  2. Using the release (or "big-bang") method, the greatest-needed functionality is made available at the same time as the least-needed functionality.

  3. My last argument is similar to the previous one, yet subtly different. Using the big-bang method, you get all of your functionality on the release date. Even if all of the functions have the same level of need, you still end up losing value. I've created a very short and simple spreadsheet to exemplify this. A screenshot of the spreadsheet is below. For the sake of this example, let's say you want to have 6 functions implemented, and each provides a value to you of $10/month. Let's also say that the 6 functions each require a month of work. Using the big-bang method, you get no value until the release at the end of the 6 months. In contrast, the spreadsheet below shows that, by the end of the 6th month, you've received $50 of value from the implementation of function 1 at the end of the 1st month, $40 of value from the implementation of function 2 at the end of the 2nd month, and so on. So whereas in the first 6 months you get $0 of value using the big-bang method, you get $150 of value using the implementation as completed method.

    Lastly, note that the example assumes that each function provides the same level of value. In reality, the implementation as completed method compares even more favorably because the greatest-value functions will be implemented first, providing an even greater value difference. For example, if the first function below had a value of $20/month, you would receive $100 of value from that function alone during the time you would be otherwise be waiting for the release.

If you have arguments for the big-bang method that you believe override my arguments above, I'd love to hear them!

No comments: