Reiterative Development

Iterative development is the method by which we take small steps in the direction of solving a particular problem, completing each step without loose ends, and gaining feedback before proceeding. So, if iterative development is good, and it is because it just is, then surely something which does more of it is more good. That's where reiterative development comes in. Reiterative development is the process of taking a small step towards developing a small feature, and then, in the next reiteration, repeating the process on the same feature in order to reimplement it in a subtley different way. This process can be coupled with pair-project-development, where you run another similar project alongside, developing a product which, were it to be released at the same time as the product the first team is developing, would be in direct competition.

Reasons for reiterative development:

• If the team ever completed the project, you might be out of a job
• If the team ever successfully captured a requirement and delivered it to be told that it was great, then you might be out of a job
• Throwing away most of the basic checks and balances for quality means that a "complete iteration" will produce something deployable, but which nobody would want, reiteration allows you to fix that without admitting that you broke it

Of course, repeating the same mistakes over and over again might get noticed; repeating the same project concurrently in different fashions, with no individual project fully capable of satisfying a full set of customer requirements, might also be noticed, so you need some excuses for why this nonsense is the right thing to do:

• Improving quality - redoing work even better is a preferable spin to "fixing our mistakes"
• Running all the options - makes it sound like you'll be providing more, even though you're reducing throughput with redundant development
• The team clearly need more coaching as they can't even get a simple requirement right - this absolves the coach from all blame, despite it being the coach's fault that the team were kept in the dark
• Once we've reached critical mass, things will speed up - a suggestion that the early reiterations will pay for later reiterations - this is part of the placebo-effect, or the illusory progress pattern
• We're making fewer reiterations - caused when you either lengthen the iteration, or reduce the amount of work in an iteration to reduce the probability of error and productivity

Remember, the longer the team are working on what you were brought in to help them with, the longer you will be in a job. It must be your business to keep the team from ever finishing or ever providing management with an excuse to declare your work complete.