Hmmm, how many iterations to do…?
I’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.
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, this nice introduction from Don Wells, Martin Fowler’s history.
One of the key ideas here is to do frequent small releases that are broken up into even shorter iterations. 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 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?)
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.
The 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.
If I thought that was really 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!).
Anyone out (including the several of you that have actually been through this course) there have anything thoughts?
No tag for this post.
January 17th, 2006 at 13:15
I think the idea of increasing the interations in a good idea, but I share you concern for the initial release and the code swaping.
What about variring the size of the interations in each release?
Release One: 2 or 3 one week interations
Release Two: 2 two-week iterations.
Release Three: 1 two-week interation or 2 week and a half interations (if you go with 2 iterations for the first release.)
Just a thought, I had to sketch a calendar to get it all to work out. You could rotate it to have the long interations first the shorter last and vice versa. I don’t remember if the student are better of with more time to figure thing out in the beginning or at the end when they want to do more fancy stuff. But that is why they pay you the big bucks!
Have a good day,
Dan
P.S. My blog has moved to my home page: http://www.danflies.com/
January 17th, 2006 at 16:28
I like that idea a lot.
In the abstract I like the idea of starting with a release of 2 one week iterations. We can then swap before the size of the code base has gotten too large and scary and then do a longer release (maybe 2 two-week iterations). You then bend and twist the last release until it fits in the time that you have and you’re good.
The details will need some love and affection, esp. since Dagstuhl and Spring Break fall at bad times, but I bet I can figure something out.
Thanks for the help!