http://www.mattmcalister.com/blog/2006/06/16/64/iterate-and-release-has-its-problems-too/ Inside Online Media Wed, 20 Aug 2008 12:26:36 +0000 http://wordpress.org/?v=2.5.1 http://www.mattmcalister.com/blog/2006/06/16/64/iterate-and-release-has-its-problems-too/#comment-52761 Aaron Smith Tue, 11 Sep 2007 05:18:29 +0000 http://www.mattmcalister.com/blog/2006/06/16/64/iterate-and-release-has-its-problems-too/#comment-52761 You raise some issues that inevitably come up when you start trying Agile. It's been over a year since you made this post, so maybe you've sorted it out. For what it's worth, I have a little input. One solid point that you raised is that it is tough to simply end one iteration and start a new one. I have found a few things that have helped in this regard. For one, it is nice to have an iteration review meeting to demarcate the end of an iteration. Discuss what was accomplished, have team members demo their work completed, and have a mini post mortem to get feedback on the process and suggestions for improvement. This helps you improve your process incrementally and then puts the last iteration behind you. Another useful practice is to plan your iteration so that development is done 2 days prior to the end of the iteration. When you spend the last 2 days in the bug fix cycle, it provides the time to tie up the loose ends, mixes things up a bit and provides a bit of a ramp down for developers in most cases, assuming estimates were reasonably accurate. When the next iteration starts, they are more likely to be ready to get back to heads down development. I have written a few articles about Agile topics like sustainable work pace, iteration planning, and other topics that you indirectly raised in your post. In case you are interested, you can read them at http://www.SmartAgile.com. You raise some issues that inevitably come up when you start trying Agile. It’s been over a year since you made this post, so maybe you’ve sorted it out. For what it’s worth, I have a little input. One solid point that you raised is that it is tough to simply end one iteration and start a new one. I have found a few things that have helped in this regard. For one, it is nice to have an iteration review meeting to demarcate the end of an iteration. Discuss what was accomplished, have team members demo their work completed, and have a mini post mortem to get feedback on the process and suggestions for improvement. This helps you improve your process incrementally and then puts the last iteration behind you. Another useful practice is to plan your iteration so that development is done 2 days prior to the end of the iteration. When you spend the last 2 days in the bug fix cycle, it provides the time to tie up the loose ends, mixes things up a bit and provides a bit of a ramp down for developers in most cases, assuming estimates were reasonably accurate. When the next iteration starts, they are more likely to be ready to get back to heads down development. I have written a few articles about Agile topics like sustainable work pace, iteration planning, and other topics that you indirectly raised in your post. In case you are interested, you can read them at http://www.SmartAgile.com.

]]> http://www.mattmcalister.com/blog/2006/06/16/64/iterate-and-release-has-its-problems-too/#comment-1437 Will McInnes Fri, 16 Jun 2006 19:11:29 +0000 http://www.mattmcalister.com/blog/2006/06/16/64/iterate-and-release-has-its-problems-too/#comment-1437 Matt - totally agree. <a>We</a> use agile-style iterative development processes to develop new websites for our clients and it's not a panacea although its responsiveness to change in the environment do massively lower risk. For example one of our clients changed a core part of their business between iterations - the next iteration gave us all the opportunity to embrace this change whereas a waterfall development process would have left the client in a stickier dilemma. Matt - totally agree. We use agile-style iterative development processes to develop new websites for our clients and it’s not a panacea although its responsiveness to change in the environment do massively lower risk. For example one of our clients changed a core part of their business between iterations - the next iteration gave us all the opportunity to embrace this change whereas a waterfall development process would have left the client in a stickier dilemma.

]]>