Section 3.2. Plan and Release FunctionalityNot Components

3.2. Plan and Release FunctionalityNot Components

The key to agility is the goal of producing customer-visible functionality with every iteration. This means that we cannot plan the coding phase in the traditional plan-driven way. The pieces of work that we plan are not components.^[1] Traditional planning would schedule engineers to work on individual parts of the system and, when they were complete, integrate them to make the system. For example, the plan would have one person (or group) develop a database interface while another person (or group) developed the GUI. Within each of these activities, people would be scheduled to develop (and maybe unit test) various classes. The weakness in this philosophy is that you don't really know whether something works until you integrate the components, so your feedback loop is very long.

^[1] In object oriented projects, components are usually classes or packages, but the essential definition of a "component" in this context is a complete architectural portion of the system.

Instead of assigning people to individual components, agility requires that each planned activity have customer-visible functionality. To accomplish this, pick small pieces of functionality from your requirements document. It's likely that each of these is a "vertical slice" of your system and will require capability in components throughout your system. As shown in the following diagram, a customer-visible feature will require modification to or creation of a variety of components throughout the system. Because architectures are often considered to have layers, this is called a vertical slice.

Figure 3.2. A vertical slice of functionality

Even though it is tempting to schedule the components of a feature, do not. It is important that the engineers see that they are responsible for user-visible functionality. That is what connects the engineers to customers, and that connection increases your ability to deliver exactly what the customer wants.

When the team has picked a set of functionality that they believe they can complete in the time-boxed iteration, there is no need to schedule tasks of finer granularity. Let the team use any method they like to determine the components that need to be built and who will build them. Track progress only by functionality completed, and that will keep the team focused where you want them.

This strategy is making two important changes. First, the team's focus is moving from developing components to developing features. This is the key to agility. Second, the team is taking ownership for the development process, estimating effort, and scheduling tasks. This self-organization will be critical to optimizing the process and spreading agility beyond the coding phase of development.

It's important to point out that the change from planning by component to planning by functionality can be very threatening to some engineers. Engineers who have been developing within one part of the system may have to move out of their comfort zone. Although they can still focus on their portion of the system, they will have to work more directly with the rest of the system for the team to produce functionality. Some engineers will see this as an opportunity to influence a larger portion of the system, but others will react to this situation with trepidation. In the short term, you may be able to shield them from this change in philosophy. In the longer term, you might want to think about pair programming as a way to help them share their expertise with other engineers while extending their knowledge of the rest of the system.