Iterative Development Happens in Your Head, not on the Calendar

Just a quick note today that I actually posted as a "comment" on another site a week or so ago, but decided to update just a bit as I thought more about it.

One of the little things I note that holds groups back, technically, from be more effective in their Agile practices is their concept of what it means to do development iteratively and incrementally. I hear and read, quite often, that teams fall into mini-waterfalls during their iterations. They take days to complete individual pieces of functionality, resulting in testing often bunching up at the end of the iteration. When I have asked developers or testers about this, their view of being iterative and incremental seems to be applied at the iteration as a whole, not their own work. Thus, being iterative and incremental has a "calendar" focus.

What they are not doing is looking at the work as a series of daily "episodes" (as many people have described/called it). They are also not engaging in TDD and/or pairing, since the ~2 hour recommended pairing time frame and the test-first approach would drive them right to a shorter cycle of creating and testing software. However, getting people to implement either of these practices can take quite a bit of effort since they require a level of collaboration which people often have not experienced in the past.

So, if there is resistance getting people to pair or practice TDD, I suggest another thing they can try which allows them to work more individually, but still in an iterative/incremental fashion of short duration. The goal is to get more frequent delivery, within the iteration, by having people think in minutes or hours rather than days, including testers. I've done this by simply asking folks to considering the following as an approach to developing a "module":

1) Create a shell with just the interfaces to other modules and test that. (Ada, for example, used to be (I'm guessing still is) great at being able validate a whole system of modules like this to ensure all interfaces pass the right number of and type of variables, for instance.)

2) Create the I/O "calls" and test them. (Yes, I am not presupposing use of OO development as my first couple of experiences with Agile iterations involved COBOL and assembler on IBM mainframes.)

3) Create the "control structure" for the module and test that. (Perhaps the hardest part of the coding/testing effort because of the combinations involved, so I even suggest doing this in increments, usually from outside in.)

4) Add the sequential data manipulation operations and test them. (I also suggest doing this incrementally based on the control structure, usually from inside out, in this case.)

The result will be shorter and shorter periods of development and test, producing earlier confidence that something "works" and closer, more frequent, collaboration between developers and testers.

Now, I'll admit that a waterfall can still be said to exist, but it is more "mini" than before and is headed in the right direction.

This also takes a few iterations to get rolling, but people began to see what being iterative and incremental, from an Agile perspective, could mean instead of just at the iteration level.

[PS: And, yes, I know about vertical slicing and Alistair Cockburn's "Walking Skeleton" as other approaches. Also, great ways to get across the idea of working in short bursts. Which is best may depend on the team and what they respond to. The idea is to get them to respond and move to the shorter time frame as their mental model for the implementation cycle.]