Got into a deep discussion with a colleague tonight over different approaches to Agile development (yes, I’m a geek; why do you ask?). I’m a Fixed Length Iteration kind of guy, particularly since I’ve spent most of time on the Operational side of the house recently. He’s a Variable Length Iteration fan, and I thought the arguments on both sides of the fence were compelling enough that I wanted to blog about them.
Really, I’m doing this for my adoring fans.
Actually, I’m doing this because I feel guilty about not blogging, and thought this was at least SOMETHING to warrant paying for a domain year after year.
Anyway, here’s the breakdown of the two arguments; let me start by spelling out some common assumptions. I’m assuming that you’re reading this because you have some interest in development, and more specifically, some interest in agile development. If you have those interests, then I’m also assuming that you know what an iteration is. If not, the hyperlinks in the previous statements should help educate you and steer you clear away from this blog to more fascinating subjects.
The Argument for a Fixed Length Iteration
There’s a couple different versions of the Fixed Length Iteration, based on either a calendar (January, February, etc.) or a cycle (every four weeks); the goal is to commit to a ship date, and stick to it time after time. I’m more of a fan of a calendar-based Fixed Length Iteration; the actual length of the iteration varies (February is short), but development is consistently wrapping up every month, and every month code is being shipped out the door. My reasons for supporting this model are as follows:
- People are cyclical creatures. We live from paycheck to paycheck; we hate Mondays and work for the weekend. Having a fixed length cycle (with some minor variation if you based that cycle on a calendar) helps in estimating and planning what gets done and when.
- A fixed cycle forces developers to think in terms of components. If you’re expected to ship working code at the end of each month, you start writing code that is bite-size, so that you can leave out pieces that aren’t finished (rather than waiting until the whole thing is done). Bite-sized code is easier to test and deploy with reduced risk.
- A fixed cycle means that it’s easy to change directions without stopping development efforts. Sometimes business priorities change; a fixed length cycle allows developers to continue moving forward until the end of the iteration and change gears there. The start of a new iteration is never far away, so most businesses can wait until the next month rather than waiting till an unknown end of a sprint.
The Argument for a Variable Length Iteration
I’m trying to give this perspective a fair shake, even though I don’t subscribe to it; in a variable length iteration model allows business and development to scope out work at the beginning of an iteration and estimate a ship date regardless of the cycle or the calendar; the goal is to allow code to mature and be more stable. My friend subscribes to this model because:
- Variable length iterations resemble traditional projects. There’s a scope estimate, requirements gathering, and work estimates (and traditional slippage). Most agile purists immediately scream “WATERFALL”, and there’s some truth to that, but a variable length iteration is comfortable to business. It’s like Mr. Roger’s house shoes.
- They lend themselves to continual shipment of code. If the iterations are variable, developers can focus on one task from start to end, and begin to operate on separate iterative cycles; if you have a development staff of 5, you could theoretically have up to 5 separate iterations going on at the same time; when a developer finishes, they ship their contribution without waiting on the sprint to end.
- This fragmentation of the iteration allows for sudden, non-disruptive change. If there are multiple iterations occurring for each independent block of code, and business needs change for one line, then only that line has to shift gears. There’s no impetus to wait; you stop where you are on the one piece, and move on to the next piece.
Your Choice?
I’d love feedback on this; as I’ve stated from the outset, I’m a fixed length iteration guy. What did I miss? Are there other benefits to the Variable Length model that I’m missing?
Stuart, first of all, good stuff. Second, I’ve had the misfortune of working in several shops that claim to be agile, but don’t quite get there. To them, fixed length really is the only way, but what I’ve commonly seen is that lines of business in these shops still think Waterfall and, as a result, don’t want partial contribution to production code. They want finished product. So Fixed Length Agile methodology only finds benefit in the close working relationship between coders, BAs and LOB contacts. What really happens is that you have 2 weeks worth of coding, some version of testing, then tabling the code until some undetermined number of fixed-length sprints until the released code can be trained at the end-user level and made useful to the production release. I still find this better than Waterfall as with Waterfall, you can spend months and months and months designing and coding requirements that have long been deemed outdated. However, I still see most shops not quite there in being able to utilize Fixed-Length or Variable-Length the way they could be used to benefit a company and LOB.
I lead toward fixed length iteration with some variation, but not on calendar month, I prefer picking a number of weeks and then, if you have a fairly big chunk of development that needs to be done in one piece, then extend one iteration.
To Jeffrey’s point: I cannot take credit for this, I heard it on a Richard Campbell interview, I believe. The quote was (paraphrased): “No one does agile. Everyone does ‘AgileBut’.”
What’s AgileBut? It’s “we’re doing Agile, but…”
Great post. I like fixed, calendar-based iterations. Agile places the decision about deliverables where it belongs, with the developers. Developers can remove a deliverable if it won’t hit be ready at the end of the iteration; they can add a deliverable if the foreseen deliverables are complete before the end of the iteration.
If you’re going to do Agile, exercise this option! Add stuff. Remove stuff.
:{>
I agree with you about humans being cyclical creatures. Especially my half of the human population 🙂
Having a regular pattern of expectations and times allows me to adjust what I’m delivering based on what I can actually get done in that period of time. As we all know – sometimes, things take longer to develop in real life than they do on the drawing board. I tend to agree with you about the practicality of having regular due dates over time.