Phase: Speculate

< Day Day Up >

Phase: Speculate Plans are guides, not straightjackets. Agile teams plan, but they recognize that reality always intrudes. Plans in this context serve as a vehicle for embracing change, not blocking it. Plans have to adapt because the customers' understanding of their requirements changes, because estimates of work effort vary because of unknowns, because people arrive or depart from the project team, and for a variety of other reasons. Plans are both conjectures about the future�our best guess at what will occur given the information we have�and guides to the future�determining what we want to occur and making it happen. Development generates new information that in turn creates the need to replan. Planning is an important activity, but speculating is a more appropriate term as uncertainty increases. Speculating establishes a target and a direction, but at the same time, it indicates that we expect much to change over the life of a project. As I mentioned in Chapter 4, speculating isn't wild risk taking but "conjecturing something based on incomplete facts or information." Plans are always conjectures about the future. When we "plan," we expect the actual project result to conform to that plan, and then deviations become project team mistakes or a sign of the team's failure to work hard enough. When we "speculate," we view the actual results positively�it's the plan we suspect was wrong. The plan, or speculation, is a piece of information, but it is only one piece that we will examine in order to determine our course of action in the next iteration. The product of the Speculate phase is a release plan that outlines, to the best of the project team's initial knowledge, a plan that is based on features delivered rather than activities. The release plan utilizes information about the product's specification, platform architecture, resources, risk analysis, defect levels, business constraints, and target schedules. There are two crucial components of an iterative planning and development approach�short iterative timeboxes and features. For software projects, iterations are generally two to six weeks in length. Hardware projects will have longer iterations and greater variation�electronic devices will generally have shorter timeboxes than, say, automobiles. Short iterations act to accelerate projects. By keeping timeframes short, teams have to figure out faster ways of accomplishing every aspect of development. For example, in serial development, major quality assurance activities are performed once toward the end of the project. In iterative development, QA activities are completed every iteration. The QA staff has to figure out how to be more effective and efficient because they perform these activities six, eight, or ten times rather than once. Feature-based development is not a software-only technique. Many hardware product development efforts are driven by first creating a product structure and then an extensive list of the features. In addition, since more and more products include embedded software, hardware and software features are both candidates for this feature-driven approach. The first goal of feature-based planning and development is to make the process visible, and understandable, to the customer team. All too often product development planning has concentrated on making the technical work understandable to the engineering team. Customers and product managers had to wade through lists of technical activities, many of which made little sense to them. A software development task such as "Create a normalized data schema design" means little to most customer teams. However, a hardware feature such as "Develop a DVD feature that will play sections of movies" resonates with customer teams. Customers understand products, components of products, and features of those components. They can attach significance (value) to these and therefore can make priority decisions about them. The engineering staff can then translate from a customer-facing view to a technical view in order to design and build the product. Features act as the interface between development engineers and customer teams�a medium for shared understanding. This shared space takes the form of a feature card. The front of this hand-written index card contains feature information for planning purposes, while the back of the card contains technical task information to enable the team to estimate effort and manage its work. Using this style of planning, product managers control which features are included in the product. Development engineers control how features are designed and implemented. Product managers wouldn't have the authority to say, for example, "We're running behind; let's cut testing time." Instead, they could only say, "We're running behind; let's cut features 34 and 68." Similarly, the development team couldn't arbitrarily add a feature because "it would be way cool." Obviously this delegation of responsibilities undergoes discussion and debate, as product managers may have suggestions about (but not final authority over) how products get built, and development engineers may make suggestions (but not final decisions) about potential features. Agile project speculating helps the project team: Determine how the product and its features will evolve Balance anticipation of features and design with adaptation as the project unfolds Focus on the highest-value features early in the project Think about the project, business goals, and customer expectations Provide necessary budget and schedule information to management Establish priorities for tradeoff decisions as changes occur Coordinate interrelated activities and features across feature teams Consider alternatives and adaptive actions Provide a baseline for analyzing events that occur during the project Everyone accepts the premise that our business world constantly changes. However, we still shrink from the implications of those changes. We still anticipate that plans won't change, at least not very much. We still view change as something to be controlled, as if we have some power over the world outside our projects. We still believe the way to reduce the cost of change is to anticipate everything at the beginning of the project. The only problem is that this approach doesn't work. If we constantly measure people's performance against the plan, then adaptability will suffer. If we want adaptability, flexibility, innovation, and responsiveness to customers as they learn new information, then we need to reward the team's responsiveness to these changes, not admonish team members for not "making plan." Through their actions, performance measurements, and vision, agile project managers constantly need to encourage teams to learn and adapt as projects evolve. Evolutionary projects are difficult�full of ambiguity, change, and uncertainty�but the rewards for adapting in order to deliver business value are great. The practices explained in this chapter fall into two categories, as shown in Figure 6.1: Figure 6.1. Speculate Phase Practices Feature Breakdown Structure Product feature list Feature cards Performance requirements cards Release Planning Release, milestone, iteration plan The final release plan can take several forms, such as a release plan spreadsheet (Figure 6.4), a feature card layout (Figure 6.5), a project "parking lot" (Figure 6.7), or some combination of these. Figure 6.4. Summary Release Plan for the CRM System (Iteration 5 is the first major milestone.) [View full size image] Figure 6.5. Feature Card Whiteboard Layout [View full size image] Figure 6.7. Project Parking Lot Plan

< Day Day Up >