Section 3.1. Start with the Coding Phase

3.1. Start with the Coding Phase

Transitioning the entire process to fixed-length iterations will require new skills in order to ensure that you develop a quality design that meets the customer's needs. So, for now, leave your existing requirements specification and design activities as they are. The results of those activities will help you continue to produce a quality system while your team is learning the skills necessary for agile development. Not only does this reduce the risk of this change, but it also demonstrates that the team still values having quality in the design of the system. Here is a diagram of what your process will look like at the end of this phase of the transition.

Figure 3.1. Phase 1fixed length iterations during implementation

The first step in moving toward agility is to make the coding phase of your existing process iterative. When you start the coding phase (or, in fact, any time during the coding phase), you should start producing customer-visible functionality in smaller, fixed-length iterations. As you continue with time-boxed iterations, you will discover other strategies to develop requirements and a quality design that will not require those activities to be separate development phases.

Starting with the coding phase also simplifies the transition toward agility because most of the coding and subsequent phases are internal to the development organization. Going to fixed-length iterations at that point does not require changing your relationship with external organizations like marketing and customers. They can feel comfortable that they have negotiated functionality in the same way they always have, which reduces the risk for them. Soon after you demonstrate the results of the quicker iterations, they will become comfortable with the new process and will be willing to accept more agile planning methods.

Taking this step will produce a fundamental change in how you do business. Remember that one of the prime motivators for fixed-length iterations was reduction in risk due to improvements in estimation. This change will cause you to make the leap from allowing scope to define release length to letting a fixed iteration length determine scope.

In each iteration, the goal is to produce some portion of actual functionality. This is a significant change in philosophy from the goal of passing milestones in a PERT chart. With each iteration, the only completed tasks that "count" are ones that produce customer-visible functionality. This doesn't mean that you don't have infrastructure-related tasks, but it probably means that those infrastructure tasks are smaller and are in direct support of visible functionality. For example, you won't have a task that implements the database-hiding layer in your architecture. However, if you are trying to allow the user to store and retrieve phone numbers, then you will have a task to develop the phone number portion of that layer. Remember: delivering functionality is the bottom line for your organization, so that's what you must focus on.

When you complete an iteration, let the team demonstrate the functionality to whoever seems most appropriate. Optimally, this demonstration should be made to the customer, but if that is not yet achievable, use management or marketing in that role. Although you need to be explicit about your understanding of the limitations of what you have developed, the demonstration is a ceremony marking the successes of the iteration. For teams that are used to waiting months or years to see the fruits of their labors, this meeting will allow them to feel the success of delivering actual functionality, which will give them motivation to continue to pursue the transition to agility.

With just this single change, the process now has a feedback loop. At the end of the first iteration, you can demonstrate functionality to the customer and receive feedback earlier. Now, instead of waiting through design, code, integration test, and system test for customer feedback, the customer (or someone representing the customer) can see actual product features very near the beginning of coding. This allows feedback and valuable insights into the direction that development should take. A fail-late process has become a fail-sort-of-early process (you'll do better soon!).

This new feedback loop is also critical to the rest of the transition process. With the advantage of almost immediate feedback, you will be able to make changes to the process while only risking one iteration of effort (as opposed to risking the whole project). The metrics generated by this feedback loop will enable you to evaluate the effects of those changes in weeks as opposed to months or years.

Clearly, this one process change is significant and includes some risk, but that risk is mitigated by two important choices we've made: we still have our requirements and design, and if things go south, we can fall back after only a few iterations.