Practice: Release, Milestone, and Iteration Plan

Practice Release, Milestone, and Iteration Plan

Objective

A release, milestone, and iteration plan presents a roadmap of how the project team intends to achieve the product vision within the project scope and constraints identified in the project data sheet.

Discussion

As I discussed in Chapter 2, agile lifecycles are both iterative and feature driven. The feature-driven aspect changes the primary focus of planning and executing from tasks to product features. Most traditional project management plans utilize tasks to construct work breakdown structures (WBSs) to organize work. [5] Although experienced project managers concentrate first on deliverables and then on the work necessary to create those deliverables, work- or task-driven plans often degenerate into very detailed, prescriptive plans. Any product has a set of features that customers use for some purpose. The more quickly we can link those customers with the features they have requested and get feedback on them, the more likely the product development effort will be successful.

[5] Ken Delcol comments, "The WBS is really an extension of the PBS and hence closely reflects the product's architecture, which the engineers understand. This is critical when functions are allocated to the subsystems (i.e., the team determines which subsystems will support which customer features/functions). If the WBS is set up this way, then there is a stronger linkage between features and subsystems."

Seasoned project managers understand that how they break the project down into work breakdown structures can have a significant impact on how that project is managed and implemented. Each possible WBS has advantages and disadvantages. A feature breakdown structure (FBS) may strike some project managers as being more difficult to administer, [6] but it offers the significant advantage of increasing interaction between the project team and customers. Phase-based WBSs (requirements, design, build, test, etc.) may be easier to administer, but they don't match how engineers actually work.

[6] With a task-based WBS, tasks are relatively permanent. With a feature-based WBS, features can be added or deleted during each iteration. This adding and deleting of features can cause resource plan management and reporting difficulties. One solution to this problem is to group features such that specific features can easily change while the group of features remains more stable.

Another advantage of basing plans on a product's features (and its architecture, which is instantiated by features) is that it keeps the project team and the customer team synchronized. It also focuses the team on delivering the product features rather than intermediate documentation artifacts.

The above statement isn't meant to minimize the importance of all forms of documentation; no one would consider building, say, an airplane or an automobile without extensive documentation. The problem is not documentation per se but that project teams often get lost producing intermediate artifacts that have little bearing on the team's real progress toward a final product. All too often, deliverables are documents, and the WBSs define document delivery schedules. In hardware development the team might deliver detail drawings, assembly drawings, test cases, simulations, specification control drawings, and bills of materialsall of which are used by the either the manufacturing organizations or the vendors to produce the parts . These documents contribute to the value generation stream. Even so, value-generating documentation has a great tendency to morph into compliance documentation. Feature-driven planning and constant thinking about value generation help to overcome this problem.

However, many project managers can't fathom a twelve-month project broken down into two-week iterations, which is understandable. Once projects go beyond four to five months, project participants usually need interim checkpoints between two-week intervals and the project's end. Larger projects that employ distributed teams or vendor-supplied components will have problems synchronizing every two weeks. Therefore many projects will require three levels of iteration. The longest period is the release cycle. Products are generally released to customers periodicallyfor example, once every year or eighteen months.

Iterations produce acceptance- tested features. The goal is to have a partial-feature product that could be deployed at the end of any iterationthat is, the features, tests, documentation, and other product deliverables could be packaged up and deployed. Actual deployment of the iterative resultsreferred to as incremental deliverydepends on a variety of factors (as I will discuss in the section on first feasible deployment).

A development team uses an iteration to concentrate on small increments of work. In software development, an iteration might be two to six weeks or slightly longer for some projects. [7] If you're building an airplane, the iterations will surely be longer (although early prototype analysis might use very short iterations). Features developed within a feature team (usually fewer than ten people who work on a group of features) should be integrated and tested by the end of the iteration.

[7] Iteration length will vary considerably across product types. Even within a single product, iterations for the hardware and embedded software features may be of different lengths, but they must synchronize at milestones.

Milestones are intermediate points, usually from one month to three months apart. Milestones can have both a project management function and a technical function. From a project management perspective, milestones provide a chance to review progress and make significant project adjustments. While some reviews should occur every iteration (e.g., a customer team review of the product), others might be appropriate at the end of a milestone (e.g., a mini-retrospective of the team's performance).

The more important use of milestones is as major synchronization and integration points. For a product that has hardware and software components, monthly (or even less frequent) synchronizations may be entirely adequate. A software product team utilizing an external vendor for a component might plan to integrate that component starting at milestone two (two months into the project) and at every other milestone after that. Biweekly synchronization with the vendor could be too costly. On the other hand, if less frequent synchronizations are going poorly, it might indicate that the synchronization should occur more often. Milestones can also be viewed as "intermediate" planning horizons.

Some components will invariably take longer, or appear to take longer, than one iteration to complete. Usually when teams are pressed to decompose a "big" component into bite- sized features, they figure out a way. Inability to break things down in this manner is usually an issue of lack of experience rather than a un-decomposable component. However, in the unusual situation in which a component's development spans two or more iterations, the project manager and team need to keep in mind the added risk involved in delaying customer feedback on it.

Two factors drive release, milestone, and iteration planscustomer value and risk. A feature may deliver high value but not be risky, or it may employ risky new technology that is invisible to the end customer. Normally the first priority in assigning features to iterations is delivering customer value as defined by the customer team, and the second priority is to schedule features that reduce risk early in the project. [8] Sometimes a technical risk takes top priority. For example, if an airplane has a performance criterion that it must fly 10,000 miles without fueling and the technology to do this is as yet unknown, then there is no point in having the customers prioritize features until the technical team has some degree of confidence that it can meet the performance requirement. All other scheduling considerationsresource availability, dependencies, and othersare subordinate to those of value and risk.

[8] The value may need to be explicitly calculated for each feature or group of features. This topic is covered in more depth in Chapter 8.

Iteration 0

Some people think agile development gives developers license to dive in and build (or code, in the software arena). They condemn agile methods, saying that such methods spend little or no time on early requirements gathering or architectural issues. On the other hand, there has been an equally negative reaction to projects in which months and months of planning, requirements specification, and architectural philosophizing occur before they deliver any customer value. There is a balance point, but the argument would lead you to believe that there is no middle ground. Iteration 0 is a practice that can help teams find that middle ground and balance anticipation with adaptation. The "0" implies that nothing useful to the customerfeatures, in other wordsgets delivered in this time period. However, the fact that we have designated an iteration implies that the work is useful to the project team.

A project to develop a large business software application, one that must be integrated with other business applications, may require some data architecture work in order to adequately define the interfaces with those other applications. In the case of an electronic instrument, the team might find it useful to create a preliminary componentization architecture. Teams utilizing unfamiliar technology may need time for training prior to a project's launch. A customer may demand a requirements document prior to signing a contract. All of these examples indicate a need for some time expenditure prior to launching into actual iterative feature development. For each of these items, a feature card (which will usually contain an artifacta shape architecture diagram, for examplerather than an implementable feature) should be created and placed in iteration 0. The need for an iteration 0 will usually be obvious before the project gets underway and will be planned as part of the Envision phase.

While the relevant issues may vary, the outcome is the samesome projects require more extensive initialization work than others. The key to effectively utilizing iteration 0 is to balance the possible advantages of further planning with the growing disadvantage of lack of customer- deliverable features. There are always tradeoffs. If the cost of a technical platform change is very high, then additional work to improve the odds of a correct initial decision may be justified. The timeframe of an iteration 0 for a next -generation jumbo jetliner will be much different than that for a portable CD player.

Iterations 1N

For most projects, the team will need to create a plan that assigns features to iterations for the duration of the project in order to get a feel for the project flow and determine completion dates, staffing, costs, and other project planning information. The resultant plan can be viewed in a spreadsheet, as shown in Figure 6.4. The project team and key members of the customer team, including the product manager, do iteration planning. The activities involved in laying out the iteration plan include:

While the product manager (together with the customer team) determines the priority of feature assignment to iterations, technical risk issues may influence her decisions. As previously discussed, customer value and risk are the primary drivers for feature scheduling. For example, in a project with an erratic requirements risk (the team realizes that requirements will be difficult to determine and volatile), the decisions on what features to implement early may be different than those for a project with high technical risk (the team has never used the technology combination before). There may be times when high-value features, which would normally be implemented first, will have to be deferred in favor of high-risk features, which need to be implemented early to reduce the risk. A risk list should be reviewed to determine what impact risk mitigation might have on the iteration plan, specifically the sequencing of features and the incorporation of high-risk items. Other considerations, such as feature-to-feature dependencies, may have some influence on scheduling, but customer value and risk are paramount.

Every project has some target delivery date selected by marketing, management, or a customer. A target establishes what someone outside the project team desires due to an understanding of the business. In the case of a co-product release (say Microsoft is releasing a new version of Windows, for which your company has a complementary product), a release date may be fixed. A target may also be used to ensure a fixed limit on development cost. While the rationale behind these dates can vary from a thoughtful analysis of the market to an off-the-cuff guess, they are important. Whether off-the-cuff or thoughtful, they represent the stakeholders' expectation. Every project also has a planned date, which the engineering team develops as part of the release planning process. Both of these dates will be used in the negotiation process, but the project team needs to understand the stakeholders' expectation, even if it is outlandish.

In many cases the target date becomes a constraint on the project. Let's say the best planning and negotiation still yield a date that the product manager, with executive concurrence, deems two months too long. The earlier date can be designated as the constraint date, provided everyone understands its purpose. Since there are many unknowns about the project, everyonethe development and customer teams and executivesworks to resolve those unknowns such that the project is completed by the earlier date. For example, everyone looks to cut features in order to reduce the scope. At the earliest time that information indicates the earlier date cannot be achieved, a reevaluation of the project would occur. [9]

[9] This process of negotiating between target and planned dates will only work when all parties are working collaboratively to achieve a common goal. It will not work in a situation in which parties are being arbitrary and capricious.

Iteration and milestone periods will vary considerably depending on the size of the project and whether it involves hardware and software, just software, or just hardware (rare today). As previously mentioned, milestones can be used for the purposes of both project management (status reporting) and technical synchronization (integrating hardware and software components). Hardware iterations may be longer than those for software, but the iterations should sync on milestone boundaries for integration testing.

For each milestone or iteration the team should develop and write a guiding theme. This is critical for focusing and ensuring that the team balances between breadth and depth of features. Theme development often evolves from the process of assigning features to iterations, but sometimes initial themes present themselves independently. These themes (e.g., " Demonstrate the basic instrument data acquisition capability"), or goals, help focus the team in ways that a list of individual features may not. Themes can also reflect risk abatement strategies (e.g., " Prove that our high-risk valve design is viable "). For large projects in which many features are being built each iteration, themes are particularly important. The best way to document the theme is on an iteration card, as shown in Figure 6.6. These cards can be used to organize feature cards on the table or wall and to record other useful information (such as assumptions) about the iteration.

Figure 6.6. Documenting an Iteration Theme

One of the reasons index cards are an effective planning tool is that they can be easily shuffled during each iteration's planning session. For small projects the team may lay cards out on a table, while for larger ones cards may be taped to whiteboards . A summary spreadsheet can show a snapshot of the entire project and maintain resource summaries. While cards should identify features that are as independent from each other as possible, dependencies will occur and influence the order of implementation. It's critical that this information be captured on the card.

Other techniques can create a more reliable schedule. The first is to add time to each iteration for changes that are identified during an iteration review. One feature card entitled " Rework and Contingency" is placed in each iteration. I've often seen plans with inspection or review tasks but without any time allotted for the changes that arose from those reviews! At the end of each iteration, an agile project goes through several quick reviews, both customer and technical. The planning phases of some agile methods imply that features are started and finished within a single iteration. Experience shows that most features actually evolve over two or three iterations as customer focus groups provide feedback. Including a rework and contingency "feature" card in each iteration (10%+ of the effort scheduled for the iteration) provides time for changes that are inevitable, even though the details aren't known.

A second technique for increasing the reliability of the schedule, particularly with high exploration-factor projects, is to set aside one or more "empty" iterations at the end of the project. These buffers are used to accommodate changes, new features, or other project alterations. Alternatively, features assigned to the last iteration or two should be those that can be dropped if necessary.

A final point about release planning needs to be made. Despite superficial appearances , this is not prescriptive planning. Even though a full release plan with features assigned to each iteration may look prescriptive, the plan is subject to review and revision at the end of each iteration and milestone.

Component- or Business Activity-Level Planning and Reporting

For medium to large projects, feature-level planning is too fine grained, at least for many customers and managers. In automotive development, for example, a parts explosion (a type of FBS) for an entire car contains thousands of small parts. Similarly, a large software application may contain thousands of features. While the development team needs to plan and deliver at a detail level, customers and managers can be more effective at a coarser level of granularity.

In such situations, a practice derived from the work of Jeff DeLuca, one of the authors of Feature-Driven Development (FDD), can help. The FDD approach relies on a granular feature hierarchy. In a customer relationship management (CRM) application development project, the hierarchy might be business subject area (Sales), business activity (Sales Analysis), and feature (Generate a Territory Sales by Product Report). For an automobile project, the hierarchy might be platform (SUV Truck Body), group (Drivetrain), component (Transmission), and feature (Construct the Shift Lever). DeLuca uses a parking lot diagram, as illustrated in Figure 6.7, to plan and report at the component (hardware) or business activity (business software) levels.

Figure 6.7 shows a plan for a CRM system that includes two business subject areas (Sales Management and Marketing) and seven business activities, each represented as a box within each of those subject areas (e.g., Sales Analysis, Prospecting, and Territory Management under Sales Management). The numbers in parentheses under the activity names indicate the number of detail features identified for that activity (e.g., 18 for Sales Analysis), and the date at the bottom of the box indicates the month and year when that activity will be completed. Large applications, like those for CRM, might have 30 to 50 activities and several thousand features. In this approach to planning, the customer team is heavily involved in scheduling at the component or activity level, while the detailed scheduling at the feature level is left to the engineering team (with involvement from customers who may have detailed product or customer resource scheduling knowledge). This "two- tier " approach to planning can be very effective. It gives the customer team a dependable and reliable planning mechanism and the development team some flexibility. [10]

[10] In FDD (for software), DeLuca breaks the technology domain into User Interface, Database, and Systems Interface features. Scheduling these features is primarily the responsibility of the development team, which schedules them as required by the customer's scheduling of business activities. For industrial products, there could be similar categories of technology features that were scheduled primarily by the technical team.

In the Figure 6.7 example, the Prospecting activity has been scheduled for completion in June 2004. Based on dependencies, resource availability, and other factors, the development team might schedule individual Prospecting features in April, May, and June. The features go through the same detail planning, development, and review process during their scheduled iteration as previously described. So, for example, if the development team scheduled a specific feature for April and it wasn't completed during its planned iteration, it would be flagged as late, even though the activity wasn't due for delivery until June.

Even with smaller projects, a hierarchy of activity and features can assist the team in thinking about a product. Listing features and then organizing them into activities, or starting with generic activities from a previous project or from product research and then identifying new features, can contribute to product understanding. In any case, the final artifacts from a planning activity include some combination of feature cards (or their electronic equivalent), an FBS (expanded upon from the product architecture practice), a feature card iteration layout, and a project parking lot.

Three Types of Iteration Plans

There are several ways to construct an initial project schedule. For example, the team can create an initial schedule by assigning features to iterations up to the target date and then determining if the scope (features that can be implemented) appears reasonable. Another approach would be to schedule all features and then compare the planned date (with all features) to the target date. Usually the target date precedes the planned date, and the engineering team, product manager, and sponsor must then negotiate, which also involves resetting expectations based on these new facts. Up to this point the target date was a desired date not grounded in an implementation plan.

However, for projects with high exploration factors, all these initial schedules can be very iffy. Depending on the degree of project uncertainty, teams might develop:

Deciding upon one of these planning approaches will depend on the nature of the project and the expectations of customers and stakeholders. The first, a complete plan, gives the team and other stakeholders a reasonable idea of how the entire project may unfold and a complete cost. This type of plan would be appropriate for a project with a mid- to upper-range exploration factor. In a two-iteration plan, the team decides on the features that will be implemented in the project as a whole and then selects the ones to be delivered in the next iteration. When there is a higher exploration factor, laying out all features into iterations may not be worth the time because of the overwhelming likelihood that much of the plan will change. The bulk of the features are scheduled in the "large" second iteration. With appropriate resource information, the team can make a stab at a planned delivery date.

For very high exploration-factor projects, the team may just select features for the first iteration, implement them, and then go on to the next iteration, with only a vague idea of how the overall project will unfold. If this strategy is employed, this "vision" of how to proceed should be discussed and agreed to in the Envision phase in order to establish reasonable expectations early on in the project. In this situation, the development team and management are learning about and managing risk based on the information discovered during each iteration. In any case, the plan remains a hypothesis about the future, not a prediction, and it will change over the life of the project. With projects of this last type, it will be very difficult to estimate a reasonable planned completion date, so a target date can be used as a constraint until a reasonable planned date can be determined.

Next Iteration Plan

Once the overall release plan has been established for the entire project, the team returns to develop a detail plan for the next (or the first, if it's the beginning of the project) iteration. The team takes each feature card and constructs a list of the technical activities required to implement the feature and records the activities on the back of the card. The team then reestimates the work effort based on the more detailed assessment and adjusts the features planned for the iteration if necessary.

Finally, team members sign up for features or activities based on their skills and/or desires. In some projects team members sign up for implementing whole features; in others they sign up for activities within features (and someone else signs up to make sure the whole feature is completed). Notice that the relevant words are "signed up for" not "assigned to" (i.e., by the project manager). Taking on the responsibility for getting the work done reinforces each individual's commitment to the project and thereby contributes to building a self-organizing team. Some teams may not have the experience or self-discipline to carry this sign-up off, but the project manager's and team's ability to make it work is a good indicator of their maturing into an effective, adaptive team.

Often in workshops or presentations the inevitable question arises, "Well, what happens if no one signs up for a particular task?" or "What happens when someone with the wrong skill set signs up for a task or feature that he is not capable of delivering?" Teams that are just learning the process might need to be coached with a gentle, "We don't leave the planning meeting until all tasks are taken." With experienced self-disciplined teams, the question never comes upthey understand task-level planning and the expectation that all tasks will be covered. In the second case, the project manager would "nudge" the team member into a different assignment, possibly pairing the inexperienced person with someone else.

First Feasible Deployment

Since there are significant benefits to early product deployment, one thing a product team can do is determine a first feasible deployment (FFD); [12] that is, the first iteration in which the product could potentially be deployed. For example, a company might be able to deploy early versions of a product to key customers who have been asking for such a product. The customers understand that the product only has certain features, but they are willing to work with that limited functionality. For the development team, early deployment might bring in both revenue and helpful product feedback. Early deployment has certain benefits but also potential costs, and high deployment costs would offset some of the benefits.

[12] For software products, this first feasible deployment is often called a "release candidate."

Teams contemplating an early deployment strategy need to think about it during initial release planning, as feature scheduling may be impacted. For example, an early deployment strategy might suggest scheduling all of the features in a particular area early such that the product would be rich enough in that one area to deploy. In the absence of an early deployment strategy, implementing features across functional areas might work as well or even better. Early deployment and beta test strategies also need to be considered together.

Iterative development creates deployable pieces of a product, whereas incremental development actually deploys pieces of the product. In some types of software developmentWeb-based systems, for oneeach iteration can be an incremental deployment. With early deployment of partially completed products, early revenue can boost ROI, and early feedback from customers can enhance the development during subsequent iterations. Other products will be difficult to partially deploy. For example, if a competitor has a product on the market with a certain capability, it may not be feasible to deploy your product until it has comparable capability. [13] And needless to say, it would be inadvisable to deploy a partial airplane.

[13] On the other hand, Ken Delcol notes that "waiting for a full-featured product can be a mistake. Partial deployment forces you to identify which of the features are most important to your customers. Most software products have way too many features that the customer rarely uses. Partial deployment when the competition has a complete product may allow you to learn something about the customer that you and the competition do not know."

So identifying the FFD iteration provides both the engineering and customer teams with an idea of when the product might first be profitably deployed. If the FFD is toward the end of the project, it indicates a potential schedule risk or may even call into question the feasibility of the project itself.

Estimating

In nearly every presentation or workshop, I get the question, "How do you estimate an agile project?" The basic answer is "Using the same techniques you already employ." There are three subtleties underlying the "how to estimate" question:

First, since agile methods are often used for high exploration-factor projects, the critical estimating question becomes "How do you estimate the unknown?" and the answer is "You can't." When there are unknowns, you are guessing, not estimatingand it's the best we can do. This is one reason why time and cost are often viewed as constraints, not estimates, in agile projects. Agile organizations learn to live with uncertainty rather than trying to demand certainty in a fast-changing world.

Second, agile projects are planned by features, whereas many project managers may be more familiar with task-based estimating. These managers have to learn to apply their experience to estimating tasks for each feature. For example, rather than estimate requirements gathering for an entire project, they will be estimating it on a feature-by-feature basis. Teams members who have spent several days identifying features and assigning them to iterations usually have a much better understanding of the product than those who have relied on task-based planning. So in most cases, feature-based planning provides better estimates.

Third, good project managers have always tried to employ progressive estimation practices (e.g., completing requirements definition prior to estimating the rest of the project), but they are often stymied by organizational demands for early numbers for budgeting purposes. Teams practicing APM can provide similar estimates for such purposes, but APM is fundamentally a progressive estimating and delivery process that mirrors the actual way product information unfolds over time.

As good project managers using task-based planning know, accumulating a project estimate from detailed estimates of either tasks or features can result in overestimating the entire project. Multiple techniquesbottom up and top down, comparisons to similar projects, using estimating toolscan help teams arrive at better overall project estimates, but they can't make up for uncertainty. While multiple techniques provide a better estimate for the entire project, team member estimates should be used for the next iteration plan. It is important for team development and cohesion that team members be responsible, and accountable, for these early iteration plans. As project iterations progress, the team members should get better at estimating for the next iteration, which should also improve the estimates for the rest of the project.

When estimating high exploration-factor projects, using distribution curves for estimates can help everyonedevelopment team members, customers, and executivesassess the impact of uncertainty and risk. For example, for a given product scope, a skewed distribution curve would show the cumulative probability of delivering on a range of dates. The curve might show that the probability of hitting the target date is 75%, while the probability of hitting the target date plus two months is 85%.

As projects increase in size, estimation requires more than team members estimating features. While teams may have a reasonable idea of how long it will take them to develop features (at least for iterations early in the project), they will usually underestimate the workload involved in coordinating with other teams. As team size increases , productivity decreases, sometimes dramatically. For example, in software development a single small team with good tools might achieve a productivity rate of 50 function points (a sizing measure) per staff month, whereas a 100-person team would be highly unlikely to achieve even one-half of that. Understanding industry norms and using software tools in estimating can provide teams with sanity checks on team estimates. Even the best team is unlikely to deliver a product in one-half the time that anyone has ever done it before.

Scope Evolution

APM approaches scope management realistically . Scope creep isn't the problem, even though many observers lament the problems with escalating requirements. Reality is more complex than an admonition to "avoid scope creep" can handle. Some scope changes are inexpensive but valuable . Some scope changes are extensive and expensive but crucial to delivering customer value. Of course scope changes can be detrimental to a project if they are arbitrary and ill thought out. But in general, scope changes that are incorporated to meet evolving customer requirements and undertaken with an understanding, and approval, of their impact on the project increase the probability of project success.

At the XP2002 software development conference in Italy, Jim Johnson of the Standish Group presented some interesting information related to scope. First, Johnson discussed two federally mandated state child welfare projectsone in Florida and the other in Minnesota. The Florida project was begun in 1990 with an original budget of $32 million, a staff of 100, and a delivery date of 1998. As of the last review, the project was estimated at $170 million and expected to be completed in 2005. The Minnesota system, with the same basic goals, began in 1999 and finished in 2000 with a staff of 8 who expended $1.1 million. Admittedly, many factors could be responsible for the differences, but a significant portion of the difference was attributed to "gold plating " requirements.

Gold plating is a type of scope creep that can be a significant problem, as the Standish and other studies (Jones 1994) show. Agile development encourages change that arises from evolving knowledge, while at the same time it discourages the gold plating and requirements bloat that often occur in traditional up-front requirements gathering. Johnson reported on two other Standish studies (one done for Dupont and another general study). In the first, Dupont estimated that only 25% of the features implemented in its software applications were actually needed. The Standish study estimated that 45% of software features were never used, and only 20% were used often or always. This points out another reason why partial deployment can be instrumental in ROI generationit may keep you from building costly but unused features! If you were able to cut project sizes in half and project teams in half, wouldn't that greatly speed development and reduce costs at the same time?

Given these numbers, it's ironic that many traditional requirements-gathering practices decry the dreaded "feature creep" as a major problem in development. I would contend that it's faster and cheaper to let features evolve over the life of the project (within some limits, of course) than to hallucinate about what the requirements are in the beginning and then build them without constant customer involvement. A strategy of building minimum features and (a very important "and") a capability to easily and reasonably adapt to change can be very profitable.

Agile development is about focus and balancefocusing on the project's key vision and goals and forcing hard tradeoff decisions that bring balance to the product. Agile development plans by feature, in customer terminology, thereby concentrating the planning process on something the customer can relate to and prioritize easily. Because plans are adjusted each iteration based on actual development experience, not someone's guesses or wishes, nice-to-have features are pushed into later iterations and are often eliminated completely.

A product's scope should be driven by customer value, technical feasibility and cost, the impact on a product's adaptability, and critical business schedule needs. It should not be held hostage to a plan developed when our product and project knowledge was still in its infancy.

The short iterations in agile development, combined with end-of-iteration customer reviews, make the entire teamdevelopers, customers, and managersface reality. We can take a requirements document and "estimate" how long it will take to develop and test the code, or we can build a small set of features and measure how long it actually took to develop them. "Yes, we estimated that we could implement 25 features this iteration, but in reality, we only delivered 15. Now what?" We now have to drop features, add staff, and/or extend the project time. Note that we do this early in a project when there is still time to compensate. Traditional approaches delay these difficult decisions until the point at which adaptive action is nearly impossible . Short-cycle reality checks keep featuritis from getting out of hand.

Short iterations also keep developers focused. With a deadline approaching every few weeks, the tendency to "enhance" features diminishes. The prioritization previously discussed emphasizes reducing the number of features undertaken. Short iterations then act to limit the size of those features. Agile practices incorporate change into the development process, while at the same time reducing project size by constant and intense concentration on essentials.

Risk Analysis and Mitigation

Since APM was designed to handle high-risk, uncertain product development projects, a separate risk analysis may seem redundant. Redundant or not, it is crucial that risk analysis and mitigation become an integral part of every APM phase and process.

Until a final product emerges, the product development process is fundamentally one of gathering and processing information. A product's design evolves from understanding requirements and constraints and the underlying science or engineering. "Will this specialized chip do everything we specified? Will this titanium piece pass our stress tests?" Product development consists of answering hundreds, or even thousands, of such questions. Each answered question, each new piece of information, reduces the risk of project failure. Planning doesn't eliminate project risks; constant gathering of information systematically reduces them over the life of the project. Gathering information costs money, so we want to constantly ask what information has the highest value. The strategies we employ to gather information should be guided in part by our risk analysisit's an integral part of the product development process and a critical component of iteration planning.

Rather than summarize what has been well documented by others about risk management, I will use some existing material to discuss how APM addresses different categories of risk. In Waltzing with Bears , their book on software risk management, Tom DeMarco and Tim Lister identify five core risks that dominate software projects:

  1. Inherent schedule flaws

  2. Requirements inflation (creep)

  3. Employee turnover

  4. Specification breakdown

  5. Poor productivity (DeMarco and Lister 2003)

First, as these authors point out, "The best bang-per-buck risk mitigation strategy we know is incremental delivery." Inherent schedule flaws occur when the size of the product to be developed is either grossly misestimated or the engineering team is given a date based on fantasy rather than reality. For a highly uncertain product, failing to meet a schedule plan may not be a flaw but merely the impossibility of scheduling the unknown. In these cases, executives and product marketing (and the engineering team) have to understand what the process of exploration involvesand what are reasonable and unreasonable expectations. While APM addresses the issue of schedule flaws in a number of material ways, no processagile or otherwisecan make up for an organization bent on the politics of fantasy.

APM techniques that address schedule risk are:

Requirements creep must first be differentiated from requirements evolution. Requirements evolution is inevitable in exploration projects; in fact it is desirable, because the cost of change remains low in agile projects, and therefore requirements evolution remains cost effective. Requirements evolution is a rational process in which the development and customer teams are constantly evolving the requirements of the product while considering other constraints such as time and cost. Requirements evolution is a joint effort in which all parties participate in deciding on features. Requirements creep occurs when there isn't a joint effort, when customers or developers add features indiscriminately. Requirements growth has acquired a negative connotation because of the high cost of change in many development efforts. Eliminate or greatly reduce that barrier , and evolving requirements become a virtue, not a vice.

Employee turnover, particularly losing a key person, remains a risk factor for any product development effort. The impact of turnover can be reduced by cross training (which rarely happens) and documentation (which conveys very little of the tacit knowledge that is so critical to success). Agile projects have built-in turnover mitigation because of the emphasis on collaboration. In software development, for example, the use of pair programming has demonstrated better knowledge sharing within the team, which reduces the impact of turnover (Williams and Kessler 2003).

Specification breakdown occurs when the customers or product managers fail to agree on specifications. For example, when an internal IT project has 10 customer departments and they can't decide on business process or business rules issues, the specification process breaks down. Unfortunately, in many serial projects, the project continues under the false assumption that the decisions will be made sometime later. The result of indecisionconflicting specifications or multiple near-duplicate featurescan have devastating results for the project. APM lessens this risk by insisting on a product manager role. The product manager, aided by the executive sponsor, is charged with either stopping specification breakdown or halting the project until the specification process can be fixed. Creating a viable specification decision-making process is the responsibility of the customer team.

DeMarco and Lister's final risk of poor productivity arises from three sources: having the wrong people on the team, having a team that doesn't work well together, and poor morale . The APM practices of getting the right people on the team, coaching and team development, and forcing reality on the project help offset these risks. Similarly, using short iterations to focus on features, feature depth, and feature value often reduces the total amount of work on a product, which contributes to ROI, if not directly to productivity.

Colleague Ken Delcol contends technology risk should be added to the list for hardware projects, and colleague Donna Fitzgerald always includes it on her list of risks for software projects. The issue in both cases is that technology can't just be assumed. On some projects a high level of technology risk is appropriate, while on others it might border on foolishness.

In addition, NPD expert Robert Cooper lists four key failure areas for new products: poor marketing research, technical problems, insufficient marketing effort, and bad timing. Cooper's list indicates that much of the success or failure of a new product is outside the engineering team's control. However it's still within the scope of what the entire teamengineering and product managementshould be constantly examining. Incremental delivery might mitigate some of these risks, but in general the development process itself won't make up for poor marketing research unless periodic reviews are held with the actual external customer (Cooper 2001). [14]

[14] A good reference for risk management in product development is (Smith and Merritt 2002).

Agile development targets risky projectsthose with high levels of uncertainty and short delivery schedules. Understanding the risks, within the context of a particular project, requires experience. Mountain climbers who get into the most trouble are those who don't understand the risks. Experienced mountaineers know their limits; they have a sixth sense about when to continue onbecause getting to the top of major peaks requires pushing oneself and one's team to the edge, but not over the edgeand when to turn back. Project teams and managers need to be visionary and positive, and at the same time, brutally honest about the risks. For project teams operating at the edge on highly risky projects, there are no formulaic answers to managing risk. APM requires the project manager to stand back from the process and constantly ask questions and monitor the situation to get answers sooner rather than later.

Risk management is a tricky proposition for project managers. On one hand, they must be realistic about the dangers facing the projectdenial leads to surprise, which leads to last-minute scrambling and firefighting. On the other hand, constantly harping on risks can demoralize a team. There are so many difficult questions about product development: Will it sell? What exactly do the customers want? What are our competitors doing? Can we deliver it on time? Can we build it for the target cost? Will the new electronic control system be ready in time? And on and on. The project leader needs to project confidence in the positive outcome of the project without glossing over the dangers. Like most of the other aspects of leadership, risk management is a delicate balancing act.

Selection of an agile approach, particularly the use of iterative, feature-based development in and of itself, reduces some risks and increases others. For example, APM projects advocate less up-front planning, architecture, and requirements gathering because information is gathered for these as the project unfolds. Short planning and delivery iterations reduce the risks of losing customer involvement, wasting up-front work as project changes occur, encountering analysis paralysis, and delaying returns. On the flip side, too little initial planning increases the risks of major rework due to oversights and scope oscillation due to hurried customer interaction, plus the increased cost of frequent reviews and changes.

Every product development project gathers, analyzes, and generates information. Teams conduct product visioning exercises that begin to concentrate the gathering process. Product designers use the gathered requirements and constraints information to solve the problem of how to build the product. Product development projects generate incredible amounts of informationinformation that needs to funnel through a systematic, iterative, feedback- intensive process.

"A totally predictable process will generate no information," writes Donald Reinertsen (1997), an expert in industrial product design. Reinertsen believes that the design process is about producing economically useful information. With a product design, until the final manufacturing engineering plans are in place, no one knows for sure whether the product can be made to the specifications that customers demand. However, as a product gets closer and closer to the "release to manufacturing" stage, the more confident the development team should be. Product development is first and foremost about generating and processing information, not predictability. If a process is predictable, if all variations are accounted for, if the process is repeatable in a statistical quality control sense of the word, then it won't generate any new information. The ideal of statistical repeatability sought by "heavy" process proponents flies in the face of product development reality.

Related

Категории