|
||||||
 |
 |
 |
 |
 |
 |
 |
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
|
|
Reprinted with permission from the Cutter Consortium.++++++++++++++++++++++ Welcome to the Agile Project Management E-Mail Advisor, a weekly electronic briefing from Cutter Consortium's Agile Project Management Advisory Service. MANAGING LARGER PROJECTS WITH FEATURE-DRIVEN DEVELOPMENT by Jim Highsmith, Director, Agile Project Management Practice http://www.cutter.com/consultants/jhbio.html I spent the last two weeks of September in New Zealand and Australia, speaking at Software Education's *Agile Development Conference* in Auckland and Sydney and working with several clients in Australia. One of the highlights of the trip was getting to renew and continue a friendship with Jeff De Luca, one of the authors of the Feature-Driven Development (FDD) agile methodology. Because he's been so busy actually managing large agile/FDD projects, De Luca hasn't written as much as some of the other agile methodologists (although he did contribute the chapter on FDD in Peter Coad, Eric Lefebvre, and Jeff De Luca's *Java Modeling in Color with UML: Enterprise Components and Process, http://www.amazon.com/exec/obidos/tg/detail/-/013011510X/cutterinformatco ). Two things struck me about De Luca's keynote address and half-day workshop at the conference. First, his focus on the people aspects of project management, and second, the simplicity and power of the "Parking Lot" for planning and monitoring large projects. The Parking Lot will be the focus of this Advisor. For large projects, feature-level planning is too fine-grained, at least for many customers and managers. For example, a nine-month project of 20 people might have 800-1,000 features (features are planned at a 1-10 days' worth of effort level). A 50-person project might have 2,500 features and feature cards. A large IT software application may contain thousands of features, and sorting through one or two thousand cards rapidly gets teams focused at too detailed a level. While the development team eventually needs to plan and deliver at a detail level, early planning with customers and managers can be more effective at a higher level of granularity. The FDD approach relies on a two-tier, coarse- and fine-grained feature hierarchy within a major business area. A feature hierarchy for a customer relationship management (CRM) application might be business subject area (CRM), business activity (sales analysis), and feature (generate a territory sales by product report). The hierarchy is part of the "shape" architecture and feature list planning that is used to initiate FDD projects. Externally, with customers and stakeholders, FDD teams plan and monitor at the business activity level. Internally, within the project team, FDD teams plan and monitor at the feature level, delving into the detail only when work on those features is about to commence. A Parking Lot consists of a large outline for the subject area with boxes for each activity (for a picture of a Parking Lot, see De Luca's FDD Web site article at http://www.nebulon.com/articles/fdd/fddimplementations.html ). A plan for our CRM system might include two business subject areas (e.g., sales management and marketing) and seven business activities, each represented by boxes within each of those subject areas (e.g., sales analysis, prospecting, and territory management under sales management). A number in parenthesis under the activity names indicates the number of detail features identified for that activity (say, 18 for sales analysis), and a date at the bottom of the box indicates the month and year that activity would be completed. Large applications, such as CRM systems, might have 30-50 activities and several thousand features. In this approach to planning, the customer team is heavily involved in scheduling at the activity level, while the detailed scheduling at the feature level is left to the development team (with involvement from customers who may have detail product or customer resource scheduling information). The same Parking Lot diagram used for planning is also used for monitoring progress. As features in an activity are begun, the color of the activity box switches from white (not started) to blue (underway). When activities are completed, the box turns green, and any activity in which features are running behind turns red. At the bottom of the box, a progress bar shows the percentage of features completed in the activity. One of the key questions in monitoring large projects is "Where are we?" The Parking Lot gives an instant, comprehensive, and very visual answer to that question even for the largest of projects. As in all agile approaches, feature completion is based on working code that the customer has reviewed and accepted, therefore the results are much more reliable in measuring completion than are traditional documentation artifacts. By posting Parking Lot data each month, anyone can quickly get a visual idea of how the project is progressing. Even with smaller projects, a hierarchy of activity and features can assist in thinking about a product. Listing features and then organizing them into activities, or starting with generic activities from a prior project or from product research and then identifying features, can contribute to product understanding. In any case, the final artifacts from a planning activity should include feature cards (or their electronic equivalent) and a feature hierarchy diagram of some type. With some minor modifications, a Parking Lot can be used with any of the other agile methodologies to enhance their application to larger projects. I've already added it to my agile project management toolkit. For more information on FDD, see De Luca's Web site at http://www.featuredrivendevelopment.com . -- Jim Highsmith, Director, Agile Project Management Practice http://www.cutter.com/consultants/jhbio.html
Get Jim Highsmith's sold-out Audio Seminar *Where and When
|
|
|
|
||
|
||||