I'm not going to waste your time on another iterative versus waterfall argument. What I would like to say is that if you're going to go iterative, everyone -- developers, testers, business analysts, project managers -- needs to be working iteratively. Some of the advantages to an iterative process are due to attaining a synergy between the software disciplines. Ideally, the testers and analysts are working on the exact same set of features as the developers. I find it much easier to establish that
ubitiquous language concept the Domain Driven Development folks talk about between developers, analysts, and testers if we're all working on the same thing. It's easier for each group to ask questions of the other groups because the subject is fresh on everybody's mind.
For a variety of reasons our tester is testing some features that we coded about two months ago. I built an exhaustive (for a developer testing his own code) suite of Fitnesse tests for all of the functionality, but without much input or involvement from the tester. Flash forward two months. We still can't technically claim the work as "done, done, done" because the tester is just now looking at it. Much worse to me is the fact that the tester isn't familiar with the Fitnesse fixtures or the system. He has not found a single bug in the backend pieces, but he's getting slowed down by the time it's taking to learn about the way the Fitnesse infrastructure is working. I'm struggling to answer some of his questions because of the length of time since I worked on these features. If we'd been able to do this together, we would have been on the same page and eliminated some inefficiency between us. I would have built the Fitnesse fixtures to *his* specification, cutting down the amount of time it's taking him to test the code.
Working a sustainable pace is usually cast as not working lots of
overtime, and that's certainly a big deal. What's not discussed as
often is the fact that the minimal overtime is purchased at a price of
no down time. The development team and the testers have to be fed with
detailed requirements for each iteration -- starting almost immediately
with iteration #1. When you're working iteratively you start coding
and testing earlier. Whoever is responsible for eliciting the
requirements needs to be communicating with the developers and testers
all the time to make sure that the next set of detailed requirements
are ready for each iteration.
I've tried in the past, and seen many other teams, to do design and coding iteratively while the rest of the team works in a serial waterfall style. It's not pretty and you lose a lot of the advantages of just-in-time requirements, continuous testing, and adaptive planning. You're just not coordinated with the rest of the team and vice versa.
While I'm ranting away, let me try to knock down a pair of common misconceptions about software lifecycles that bug me:
- Spiral (or Iterative only) and Iterative & Incremental development are two very distinct lifecycles. An iterative process means that you take a subset of the whole and work that subset to production quality code that could be deployed before starting the next subset. A spiral process is developing the whole system in a series of prototypes with increasing quality until the whole is ready to ship. There are people who argue which is more effective, but they are distinctly different (my opinion is that Spiral is a bad idea because people just rush the early prototypes into production). Here's a pro-prototyping, anti-Emergent Design link (points for the photo of the 360 bridge in Austin on the page). I disagree with basically everything ever written on Software Reality, but in the interest of balanced coverage...
- Agile versus Waterfall is a false dichotomy. Every Agile process is *an* iterative & incremental process, but not every iterative process is Agile. A big portion of the folks I see actually try to defend waterfall development are really just trying to take an anti-Agile stand because they're irritated at the hype. RUP is supposed to be iterative. ICONIX is iterative. MSF is supposedly iterative. None are Agile processes. You *can* work iteratively in a formal process.
Lastly, an iterative cycle doesn't mean that you build a different application layer per iteration. That's BDUF all the way. If you're working iteratively you should be building completely functional features, so you're going to have to work vertically, not horizontally. Building a layer at a time is a great way to fail dramatically or work inefficiently by creating speculative code.