Employ Iterative, Feature-Based Delivery

< Day Day Up >

Employ Iterative, Feature-Based Delivery If you want to innovate, you have to iterate! The serial, or waterfall, development lifecycle has been under attack for years, but it still has its defenders. For example, Donald Reinertsen (1997) writes, "The vast majority of academic literature on product development is skewed towards the sequential approach. This is in striking contrast to the enormous shift that has taken place in managerial practice towards a more concurrent approach." In the software development field, the attack on waterfall approaches goes back decades, as thoroughly documented by Craig Larman (2004). As Larman recalls, a 1970 paper by Winston Royce was credited with starting the "waterfall" trend. In fact, Royce was an advocate of iterative development for anything more than simple projects. In 1985 the US Department of Defense adopted a waterfall-based standard (DOD-STD-2167), which it largely abandoned for iterative methods after experiencing high failure rates. But even though serial approaches have been attacked as too simplistic, not only do they continue to be widely used, they continue to influence contracting procedures and executive perspectives. So in order to respond to the widespread misinformation about serial development, teams that practice APM need to understand why iterative, feature-based delivery is useful, and in fact critical, to innovative product development. Creating a Better Product Iterative, feature-based development can be defined by four key words: iterative, feature-based, timeboxed, and incremental. Iterative development means that we build a partial version of a product and then expand that version through successive short time periods of development followed by reviews and adaptations. Feature-based delivery means that the engineering team builds features of the final product or, particularly with industrial products, at least a close representation of the final product (such as a simulation model). Iterations are constrained to produce a result within a certain period of time�a timebox. Timeboxes force closure; they force us to make something concrete, often before we are quite ready. Incremental development means that we build these partial products such that they will be deployed at the end of one or more of the iterations. Partial products can be delivered in hardware to allow for earlier testing of key performance attributes. For software companies, iterative development and incremental delivery have become a competitive advantage. Short, timeboxed iterations are a fixture of APM. However, iterations are only half the story�features, rather than tasks, are the other. Customers don't understand, nor do they care about, the engineering tasks required to build a DVD player or an automobile. They do, however, understand the features of each of those products. If we are to build products that deliver customer value each and every iteration, then the highest-level control on the process must be features about which the customer can say, "Yes, that feature does what I expected it to do, and it is valuable." Saying to the customer at the end of milestone 1, "Yes, we finished the relational database schema" or "We got the CAD drawings of the fluid transfer valve done" just doesn't work. This information isn't something the customer can relate to, much less make a priority decision about. The feature delivery approach helps define a workable interface between customers and product developers. Customers get to schedule and prioritize features; product engineers figure out what tasks will be necessary to deliver those feature and what it will take in terms of time and cost. Showing a customer a task plan can be dangerous, as they'll often ask, "What's this four weeks at the end for testing? Can't we cut that down?" This feature-based approach applies to everyone else, too. Senior management is restricted to feature management, rather than task management; they can cut features but not tasks. For projects and products in which the requirements can evolve over time, it is critical that the results reviewed by customers during the development process be as close to versions of the actual product as possible. Customers have a very difficult time visualizing from documents how a product will function, which is why in industry after industry, companies have embraced modeling, simulations, and prototyping to improve the feedback loop from customers to the development teams. One of the four core values of agile project management speaks to "working products over comprehensive documentation," indicating that customers respond to real versions of products they can actually use. Shoe developers build versions of shoes during the development process. Airplane designers use extensive simulations (that are heavily visual) to make sure systems will integrate well before spending hundreds of millions of dollars building the first version of a plane. Automobile designers build both full-scale and reduced-scale models of new cars. In each of these cases, the developers have support documentation�but the proof is in the actual product. Whether the feature is implemented in a prototype, model, or simulation has to do with the cost. Software features can be demonstrated fairly inexpensively and then be easily changed. Building versions of an airplane would be much more expensive, hence the industry's heavy reliance on simulations. Michael Schrage (2000) describes the differences between models, simulations, and prototypes in his book Serious Play. He then goes on to say, "In effect, models, simulations, and prototypes have become 'flavors' of the same thing�the effort to use technology to re-create some aspect of a reality that matters." And what matters is that the project team and the customer team have common ground, a shared space, in which to discuss, debate, and decide on critical product feature issues. Features are closer to reality than other intermediate artifacts. They indicate real, not artificial, progress. Once we are faced with real progress, project teams, customers, and stakeholders are forced to confront the difficult tradeoff decisions around cost, schedule, and scope. Customers, product managers, and other stakeholders can no longer be indifferent bystanders in the development process. Iterative development, when accompanied with reasonable end-of-iteration reviews�product, technical, process, team�is also self-correcting. For example, architecture is considered, in the serial development world at least, as complete near the beginning of a project. However, several types of feedback can indicate poor architectural decisions. Finding extensive integration problems at an iteration or milestone can point to poor coordination between subteams, poor component or module subdivision or interface designs, or a combination of both. Iterative development teams expect to confront problems like these and either evolve the architecture or put additional coordination mechanisms in place. Probably the most important aspect of self-correction is customer feedback on the product as it evolves. As these evolutionary changes get incorporated in later iterations, the customer's confidence in the product grows, or conversely, it becomes clear that the product isn't working and should be abandoned�early. Producing Earlier Benefits Driving exploration is critical, but knowing when to stop is also critical. Product development is exploring with a purpose, usually within a set of constraints. Frequent, timeboxed iterations compel the development and customer teams and executives to make difficult tradeoff decisions early and often during the project. Feature delivery contributes to realistic evaluations because the product managers can look at tangible, verifiable results. In my early years of iterative development, I thought timeboxes were actually about time�making sure things were accomplished within the specified timeframe. What I came to realize is that timeboxes are actually about forcing tough decisions. If a team plans to deliver 14 features in an iteration and it can only produce 10, then the development team, customer team, and possibly the executive sponsor must face the shortfall and decide what actions to take. Many factors will influence the decision making�whether this iteration is early in the project or late, whether the shortfall will impact the delivery date or product viability (every product has a set of features that constitutes the minimum viable set)�but the salient point is that these decisions are addressed frequently in an agile project. All too often, sequentially developed products reach the final stages, only to discover major problems when the options available are limited. By forcing difficult decisions early and often, timeboxed feature delivery gives the team more options for solving problems. Iterations allow you to manage risk sooner�you do not have to build the whole product to find out if you can meet a particular specification. Another benefit of continuous feature delivery is that for some products, software being a good example, incremental releases can provide early benefits. Rather than wait 12 or 18 months for new software features, incremental delivery can provide quarterly or even more frequent ones. Incremental releases can favorably alter ROI calculations because they allow product managers to address opportunities that would be lost in 18 months. However, even though some products can be developed iteratively using simulations or prototypes, they are very difficult to release incrementally. As the battle over Web browsers showed in the late 1990s, customers often can't assimilate new product releases every three to four months. Progressive Risk Reduction Product development is risky business. As Tom DeMarco and Tim Lister (2003) so pithily state, "If a project has no risks, don't do it." "Risk is an essential characteristic of product innovation," says Preston Smith. "Product development involves innovation…there are always pieces of information that we need now that will not be known until we are further downstream" (Smith and Merritt 2002). Risk covers a wide range of topics, from technical (can we build it?) to marketing (can we sell it?) to financial (can we sell it at a profit?). In many organizations risk management is a "bolt-on" to project management activities: "Well, we'll do some risk management if we have time." Iterative, feature-based development integrates the consideration of major risk issues directly into the process. At each stage of planning and development, the customer and engineering teams discuss both business value and risk: "What features are highest priority from a business value perspective?" and "What features will have the greatest impact on risk reduction?" Sometimes the answers to these questions are the same features, sometimes not, but in certain respects the two questions are just different perspectives on the same issue�delivering value. For example, in a planning exercise for a product, there may be a combination of technical risk (a new technology architecture for us) and feature risk (we're not sure what the features should look like). In prioritizing features for iteration planning, the team will need to balance a strategy of broad feature implementation early (to reduce feature risk) or in-depth technical development (to reduce technology risk). Sometimes the highest "value" will be to reduce the technical risk first.

< Day Day Up >