{"id":297,"date":"2006-01-13T17:29:14","date_gmt":"2006-01-13T22:29:14","guid":{"rendered":"http:\/\/UnhinderedByTalent.com\/Phi\/?p=297"},"modified":"2006-01-13T11:30:06","modified_gmt":"2006-01-13T16:30:06","slug":"hmmm-how-many-iterations-to-do","status":"publish","type":"post","link":"https:\/\/UnhinderedByTalent.com\/Phi\/archives\/2006\/01\/13\/hmmm-how-many-iterations-to-do\/","title":{"rendered":"Hmmm, how many iterations to do…?"},"content":{"rendered":"

\"Extreme<\/a>
\nI’m teaching our Software Design and Development course again this semester after what I think is the longest hiatus I’ve ever had from the class (1.5 years!). This break is giving me a nice (and somewhat frightening) chance to see some things afresh and ask some questions about how some things have been handled historically.<\/p>\n

One thing I’ve been contemplating is the number of releases we want to run. We run a fairly agile\/XP process; for more see the Agile Manifesto<\/a>, this nice introduction from Don Wells<\/a>, Martin Fowler’s history<\/a>.<\/p>\n

\"Agile<\/a>
\nOne of the key ideas here is to do frequent small releases<\/a> that are broken up into even shorter iterations<\/a>. Historically I’ve usually done 3 releases, each composed of 3 (or sometimes 2) one week iterations. Re-reading the Bob Martin’s excellent Agile software development<\/a><\/cite> and thinking about how that’s gone in the past, I’m wondering if it might make more sense to two 2 releases, each composed of 2 two week iterations. The problem is that a 1 week iteration doesn’t give you very much time for planning and tracking, especially since everyone is “part time”. Martin’s text, for example, suggests two week iterations (for full time employees!) with a planning\/tracking meeting half-way. (With one week iterations we try to have something like that mid-week, which gives them feedback sooner, but we tend not to do it every week because it would just take up too much time, etc., etc. So maybe two week iterations are just more honest?)<\/p>\n

I see two possible downsides to this. One is that a two week iteration is a long time, giving groups more time to delude themselves that everything’s OK and they’ll pull it all out in the end. The mid-point planning\/tracking meeting\/report will help mitigate that, but it won’t make it go away.<\/p>\n

\"Numbered<\/a>
\nThe other is that we only get two releases which cuts down on several opportunities for pedagogical fun. One thing I’ve often done, for example, is have groups swap code bases after the first release and see how much fun it is to deal with someone else’s code in the second release. We then get the third release to pull everything back together and reduce the amount of chaos.<\/p>\n

If I thought that was really<\/em> important to do this kind of swapping I could make them swap in the middle of the first release, so everyone does a single two week iteration on Project A, and then switches to Project B for the second iteration. Then they’re also stuck with that group’s planning and estimates, which could be fun (or a complete mess!).<\/p>\n

Anyone out (including the several of you that have actually been through this course) there have anything thoughts?<\/p>\nNo tag for this post.\n\t

Related posts<\/h4>\n\t