Early And Often

Other names: Incremental development, Fountain /spiral/tornado development, EarlyAndRegularDelivery, Staged delivery.

Problem: A completed task or product isn't, and requires several iterations to get to where it is already supposed to be. (See examples)

Forces:

• Development of some deliverable is expensive.
• The first version of the deliverable almost assuredly will not be acceptable
• Iterative corrections to the first version of the deliverable are not accounted for in the schedule.

Resolution:

• Create a minimally functional version of the deliverable
• Ensure that the minimal functionality is correct
• Add Features/Functionality/Detail incrementally, assuring correctness after each addition.

Comments: This pattern shows up in a wide variety of contexts. I'll mention two examples here:

Coding - Writing the code for a large module will contain a number of syntactical errors. Generating the code all at once and then trying to compile it at the end leads to an unmanageable number of errors, many of which are in code that hasn't been looked at in a while. Under EarlyAndOften, the first compilation occurs after the interface definitions are coded, possibly with stubbed out implementations. Once this compiles correctly, each function is implemented, with a compilation cycle after the completion of each function. The result is that the errors are collected into smaller more focused groups.

Design Reviews- Except in the simplest of cases, designs presented for review are subject to some sort of revision. If a full design is presented, and the revisions include architectural changes that redefine or eliminate components, the work in developing those components was wasted. Likewise, any effort towards putting those components into a formal format is also wasted. Doing informal reviews (where the focus is on the design rather than the documentation, see CampFire) of first the architecture, and then the components reduces the amount of lost effort by the developer. Care must be taken to keep the review sessions short, with the goal of spending little more total time on many short reviews than fewer longer ones.

-FriedrichKnauss

---

Delighted to see more of this being described. I was looking to see if EarlyAndRegularDelivery was listed in the WikiList, and found this, with a shorter name! Here is my version of this same pattern (taken from http://members.aol.com/acockburn/riskcata/riskbook.htm) in a slightly squished form:

Thumbnail: You don't know what problems you will encounter during development, so... Deliver something early - discover what you don't know you don't know; Deliver regularly - improve each time.

Indications: You are unsure about some part of your development process / You just wrote a project plan with a first deliverable after two or more years of work / You want to improve and optimize your process

Forces being balanced: You need more knowledge to plan or set up the project / You have to move forward into the project.

Factors affecting the balancing of the forces: Your missing information is related to the process as well as the product / You are already committed to producing the system.

---

The real reason I was looking for this page is to add an example of use. My wife and I were packing our house to move countries. We had 28 days left, and virtually no packing done. We started on the bedroom, the easiest one(EasiestFirst?), and after 4 days still were not done with it! I counted 17 rooms, including parts of the basement and the garage. It was quite clear to me we were not going to make it. So I applied two strategies: EarlyAndRegularDelivery and VisualStatus.

According to EarlyAndRegularDelivery, we should not try to pack half of each room, but we should try to pack one room to completion - in order to learn what surprises lie in wait in the last parts of packing a room, and how long it really takes to complete the task. It took us 4 more days for that room, and the ending dragged on forever, with always "just a few more things to put in".

I made a list of the 17 rooms, and desired completion dates. It was completed clear to me, but not to my wife, that we would never make it. We were going to be out of the country by about room 6.

So I applied VisualStatus (example given more fully there), and made a graph of rooms vs. time. It was clear to the most casual observer how far behind we were, and what we needed to do to get done in time. This actually worked, and I am happy to say we completed the last room on the last day. The chart helped us see when we had to work like dogs to catch up a bit, and then it showed when we were relaxing too much. It made me a real fan of VisualStatus as well as EarlyAndOften.

AlistairCockburn