High Level Iteration Cycle Standards

8/14/00 - Go Back

These standards are at a high level and are thus more encompassing and stable. Low level standards tend to vary depending on organization, project, domain, skill levels and personal preferences. These are elsewhere, including areas such as modeling techniques and coding rules.

---

First pause to examine our diagram of the Iteration Cycle process. This gives you the conceptual overview instantly.

Every significant project has a Release Plan. Each release is composed of one or more iterations. Each iteration produces tangible results. The most important result is the product shipped to the customer. Supporting it are a fleet of artifacts such as documentation, source code, models, analysis and plans. To do all this well a sequence of activities, bettter known as steps, are used. These steps and their standards form a repeatable process.

If each engineer decides how to approach each step, or worse yet, uses their own steps, production falls into chaos except for known domains and simple projects. But if engineers perform each step in sequence as needed, and follow the standards the group has agreed upon, bliss and perfection are sure to follow. :-)

Note how process flow can branch when problems or opportunities arise. When Testing discovers a problem, the flow goes to the step where the defect was injected. Similarly, once Testing is done we take the time to Refactor the product and artifacts. Seizing these opportunities causes the flow to go to the step where the opportunitiy is best first addressed.

Here are the high level standards for each process step, in approximate order of importance. Low level standards are usually unique to each orginazation or project.

Release Plan

Contains a clear high level set of cohesive project goals.
Contains a series of small releases.
Each release has its own smaller set of cohesive release goals.
All goals can be tangibly measured for achievement.
Each release has a theme and expected date of completion.
The Release Plan is current at all times.
Higher risks and more important customer requirements receive priority.
Key metrics are collected and publicly displayed, including schedule variance, defect levels and customer satisfaction surveys.

Tangible Goals - "All goals can be tangibly measured" is subject to frequent disbelief, but can be done in all cases. For example suppose you have the goal, "The final product must be be better than all competitors in its niche". That just won't do. "Better" is noble but hopelessly vague. Reword the goal to. "A survey of 40 users with 2 years product niche experience minimum will show that over 75% prefer our product over all competitiors in the foreign language spell checker niche".

Design your Release Plan to get the product into the customer's hands as soon as possible, to begin the feedback loop.

Iteration Plan

Iteration cycles produce output that is not for general release, although it may be made available for customer testing or reviews. Each iteration progressively adds more functionality to the product in a strategic order, just like release cycles.

This includes all points in the Release Plan, except they apply to the Iteration Plan. For example an Iteration Plan has general goals, has a series of small iterations, etc.

Each iteration is broken up into small cohesive tasks.
Each task is clearly defined in writing, or the task name is so descriptive to the team that the implications are obvious.
Iterations are fairly short, 1 to 3 weeks.
Staffing and assignments are determined as early as possible. In the case of engineers selecting preferred next tasks, only staffing need be predetermined.
An iteration is done when requirements and standards are achieved. Avoid over polishing.

Design your Iteration Plan so the project hums along at a rapid easy rate. By rapid we mean frequent visible product growth. By easy we mean well extracted tasks done by great people using a good process.

Analysis

Analysis determines in detail what's needed. It describes what functional results will be in the product from the customer's perspective. It avoids describing how the results will be achieved, unless that's necessary. For example a certain workflow may be preferred.

Focus on what users need to accomplish, not how unless that clarifies.
Take a multi-dimensional look at requirements for a complete perspective.
Present the analysis in a concise, simple, easy to read format that makes subsequent steps a pleasure. Avoid large documents or any large areas of text.
Validate the analysis by review with customers or their equivalent.

Analysis includes at a minimum these artifacts or their equivalent: (See Mini Process 2 for details)

Nutshell Vision
Narrative (optional for very small projects)
----- Followed by -----
Key High Value Goals - From customer and business viewpoint
Use Cases or Customer Stories
Traits (optional for very small projects)
Risk Management (optional for very small projects)

Use Case - A Use Case is a series of steps an actor performs on a system to achieve a goal. They are very effective for capturing what a customer wants in the customer's language. Indeed, they can easily be identified and written by customers. Identification just lists the Use Cases needed. Elaboration adds the steps and descriptiions if needed.

Customer Stories - A Customer Story describes, in 1 to 3 sentences, something the customer wants. It may be a Use Case, a change to the system, a vague feature, etc. The idea is all iteration cycle tasks consist of fulfilling Customer Stories. They are used in XP instead of Use Cases and Traits.

In my opinion, this XP technique falls a bit short because it lacks the rigor and clarity of Use Cases and Traits. A "change to the system" story is best approached as a change to an existing Use Case, which preserves the original rationale, which tends to preserve the conceptual integrity of the system. A "make it speedier" story is best classified as a trait and all developers made aware of it, unless localized. Customer Stories lack a clear goal, actor and means, unless added. However, Customer Stories are easier to use because less work is required short term, and so are popular in XP.

Do a good analysis to avoid doing the wrong things right. Do the right things right.

Following this analysis process will result in design being a cake walk. :-)

Design

Design expresses the intentions of the emerging system. It captures what do to but not how. Modeling is synonymous with design, regardless of the field. In software modeling is best expressed with standards like ER diagrams, GUI mockups and UML, with descriptive text as needed.

There are a few rules of the road in design:

Design the Acceptance Test before the Functional Design whenever possible.
Model before you code, unless deliberate throwaway exploration. Avoid hacking.
Change the model before you change the code. This keeps you thinking at the higher level of design intentions.
Keep most models on one page. Drill down do other pages for subsystems. If a subsystem cannot fit on one page, remove detail until it does, such as methods, but have a drill down that has all the methods.
Identify the non-obvious patterns used.
Always show inter-system relations and use a system boundry dotted line.
Identify the system or partition at the top of the page.
Identify what is implemented and what's not, unless 100% or 0%.
Use noun phrases for class, field, partition and system names.
Use verb phrases for methods.
Show enough for conceptual comprehension, but not so much as to cause overload.
Validate the model by insuring it supports all analysis items.
Always have architecture. Without it your strategy cannot be communicated well.

Following these design rules will result in implementation being trivial instead of your main challenge.

If a process step is hard, look upstream for the culprit, or fix the process.

Implementation

Implementaiton defines the precise behavior of the system. By using the word "implementation" we emphasize it followed logically and easily from a design. "Coding", on the other hand, has no such implication.

The most important goal of implementation is understandabiility, allowing those who come after you (and you yourself) to make changes.
Implement the test before functionality whenever possible. This increases depth of understanding of what you're about to do and allows "writing to the test".
Proceed in an "implement the model" mindset, one portion at a time.
Follow your group's Coding Standards.

That which cannot be understood cannot be changed intelligently.

Testing

Testing determines whether an implementation meets requirements and standards.

Have as much testing as reasonable be done concurrenly by the designers and implementers. This integrates quality with behavior in a subtle and wonderful way.
Use as much automated testing as possible.
Do usability testing as early as possible and as frequently as needed.
Keep the product in an "always shippable" state at all times. If integration tests fail, back out changes unless immediately corrected.
Establish and use a small set of metrics.

Testing can only prove the absence of identified defects. It cannot prove the presence of quality. Use brainpower for that. However, testing can increase the odds that you have high quality in some product areas.

Since testing determines whether something meets requirements and standards, your requirements and standards must be high quality and written down. Otherwise you're testing which way the wind blows today....

Quality is far more people than test dependent.

Refactoring

We define refactoring as improving existing work products. This is less limiting than the definition used by Martin Fowler in the book "Refactoring", which defines it as "Improving the quality of existing code". IMHO that is too narrow minded.

This means you have the process step and the time to improve your Analysis, Design, Implementation and even Testing work products. Jump on that opportunity but avoid over polishing the apple.

Avoid skipping improvement to meet deadlines. Instead do needed improvements anyhow and change the deadline. The long term effect will be positive.
Refactor as soon as possible after spotting a needed improvement.
Refactor all the time rather than in chunks of just refactoring. Exceptions are for major redesigns and such.
Focus on requirements and design more than code. You will get a better return on investment.
Include the process itself and standards when refactoring. This is the ultimate feedback loop.
Refactoring is a type of rework. Learn to differentiate between avoidable and unavoidable rework. Eliminate the root causes of avoidable rework.

Budget about 1/3 your time for improvement. Less than that encourages entrophy. More than that encourages sloppy work. Discover your own optimum percentage.

Take the time to train people in skills, including process use. Low skill levels are the leading cause of bad work, which requires rework, either in the form of bug fixes or refactoring. Rework is one of the leading causes (though not a root cause) of project cost, time and quality problems.

---

Some considerations:

Double Doing

Double Doing (DD) is the practice of two people doing the same thing together. This is similar to XP's Pair Programming where two people do production programming on one machine. Popularizing Pair Programming may be XP's greatest contribution. We use the term Double Doing to allow applying the practice to much more than programming.

DD is a counter intuitive practice. At first blush it seems wasteful of your most precious resource. However experience is showing that it improves overall team output. Here are some reasons why:

Education - DD exposes you to how someone else does things in intimate detail. It's as if you're in perpetual training. Good habits rub off quickly. Bad habits are gently erased. Facts about this and that transfer from brain to brain at mindspeed, because the fastest and best way to learn is by doing. Also, most organizations do not give enough training and most individuals do not do enough self education. DD corrects this imbalance.

Two Heads Are Better Than One - The old adage comes into play here. Two pairs of eyes are looking at each decision, making each one potentially better. Two brains are spouting off possibilities, giving a greater range to choose from. Etc. Perhaps the main reason two heads are better is the instant feedback that occurs from "your other head".

High Low Perspective - The person not at the keyboard can think at a higher level, such as a few steps ahead, or about quality, or jot down a refactoring opportunity. The person at the keyboard is emmershed in low level detail, such as what code to type in, how to move an icon on a diagrammer, how to best compose a sentence.

The human mind's short term memory is limited to 7 plus or minus 2 chunks. These are quickly exhausted in pursuit of any demanding task. Worse yet, the mind settles into a state of flow (deep concentration) where short term memory becomes ultra focused and has no room for extraneous concerns. For example when coding one becomes super code oriented and thinks little of strategic concerns. Limitations like these are where DD helps. DD broadens the spectrum of what the pair mind is concerned with. the 14 plus or minus 4 chunks are enough to envelop both a broad and detailed perspective of a task.

Freshness - By switching who's got the keyboard, one gets a mental break frequently. Although you're still working, switching to a different type of work is refreshing. By continually rotating who's at the wheel, a pair can keep up a high level of steam much longer than when working alone.

Vanity - Ahhhh, our Achille's heel becomes a strong point. When humans communicate they want to look good in the other's eyes. Peer esteem is one of our strongest needs. So when two people are working closely together, each is striving to do better work so as to look good in their partner's eyes.

Note not all of this holds true for all engineers. Some work best alone or cannot tolerate working with a novice. Some types of work, such as architecture, concept creation and portions of design, are so creative and requre such deep concentration that DD is counter productive for some people. Find what work is best done with DD for what people in your organization.

We recommend Double Doing for most process steps and most people. With experience we will be able to make more exact recommendations and say why.