foundation leads. These are not always easy questions to answer, and organizations will have different answers for different stages in their evolution and for different projects in their portfolio.

An Agile Case Story

Jeff De Luca, project director of Nebulon, an information technology consulting firm in Melbourne, Australia, offers an example of an agile methodologys success using feature-driven development (FDD). De Lucas project was a complex commercial lending application for a large Singapore bank utilizing 50 people for 15 months (after a short initialization period). I tracked De Luca down looking for an FDD case story for my book, and subsequently spent several hours on the phone and exchanged many e-mails with him. Previously, the Singapore lending project had been a colossal failure. Prior to De Lucas involvement in the project, a large, well-known systems integration firm had spent two years working on the project and finally declared it undoable. Its deliverables included the following: 3,500 pages of use cases, an object model with hundreds of classes, thousands of attributes (but no methods), and, of course, no code. The project an extensive commercial, corporate, and consumer lending system incorporated a broad range of lending instruments (from credit cards to large multi-bank corporate loans) and a breadth of lending functions (from prospecting to implementation to back-office monitoring). The scope was really too big, said De Luca. FDD arose, in name at least, in 199798 when Nebulon took over the Singapore project. De Luca had been using a streamlined, light-process framework for many years. Peter Coad, who was brought in to develop the object model for the project, had been advocating very granular, feature-oriented development but had not embedded it in any particular process model. These two threads came together on this project to fashion what was dubbed FDD. Less than two months into the new project, De Lucas team was producing demonstrable features for the client. The team spent about a month working on the overall object model (the original model and what De Luca refers to as the previous teams useless cases were trashed). They spent another couple of weeks working on the feature decomposition and short iteration planning. Finally, to demonstrate the projects viability to a once-burned and skeptical client, De Luca

large projects. In the mid-1990s, my interest in complex adaptive systems began to add a conceptual background to the team aspects of the practices and was the catalyst for the name change to ASD. Complexity theory helps us understand unpredictability and that our inability to predict does not imply an inability to make progress. ASD works with change rather than fighting against it. In order to thrive in turbulent environments, we must have practices that embrace and respond to change practices that are adaptable. Even more importantly, we need people, teams, and organizations that are adaptable and agile. The practices of ASD are driven by a belief in continuous adaptation a different philosophy and a different life cycle geared to accepting continuous change as the norm. In ASD, the static plan-designbuild life cycle is replaced by a dynamic speculate-collaborate-learn life cycle. It is a life cycle dedicated to continuous learning and oriented to change, re-evaluation, peering into an uncertain future, and intense collaboration among developers, management, and customers.
A Change-Oriented Life Cycle
not know everything. The second conceptual component of ASD is collaboration. Complex applications are not built; they evolve. Complex applications require that a large volume of information is collected, analyzed, and applied to the problem a much larger volume than any individual can handle by himself or herself. Although there is always room for improvement, most software developers are reasonably proficient in analysis, programming, testing, and similar skills. But turbulent environments are defined in part by high rates of information flow and diverse knowledge requirements. Building an e-commerce site requires greater diversity of both technology and business knowledge than the typical project of five to 10 years ago. In this high-information-flow environment, in which one person or small group cannot

A change-tolerant

business not only responds to changes in the marketplace, but also causes changes that keep competitors off balance.
possibly know it all, collaboration skills (the ability to work jointly to produce results, share knowledge, or make decisions) are paramount. Once we admit to ourselves that we are fallible, then learning practices the learn part of the life cycle becomes vital for success. Learning is the third component in the speculate-collaborate-learn life cycle. We have to test our knowledge constantly, using practices like project retrospectives and customer focus groups. Furthermore, reviews should be done after each iteration rather than waiting until the end of the project. An ASD life cycle has six basic characteristics: mission-focused, feature-based, iterative, time-boxed, risk-driven, and change-tolerant. For many projects, the requirements may be fuzzy in the beginning, but the overall mission that guides the team is well articulated. A mission provides boundaries rather than a fixed destination. Without a good mission and a constant mission refinement practice, iterative life cycles become oscillating life cycles swinging back and forth with no progress.

The ASD life cycle focuses on results, not tasks, and the results are identified as application features. Features are the customer functionality that is to be developed during iteration. The practice of time boxing, or setting fixed delivery times for iterations and projects, has been abused by many who use time deadlines incorrectly. Time deadlines used to bludgeon staff into long hours or to cut corners on quality are a form of tyranny; they undermine a collaborative environment. It took several years of managing ASD projects before I realized that time boxing was minimally about time it was really about focusing and forcing hard trade-off decisions. In an uncertain environment in which change rates are high, there needs to be a periodic forcing function to get work finished. As in Barry Boehms spiral development model [3], analyzing the critical risks drives the plans for adaptive iterations. ASD is also change-tolerant, not viewing change as a problem but seeing the ability to incorporate change as a competitive advantage. eXtreme Programming XP, to most aficionados, was developed by Kent Beck, Ward Cunningham, and Ron Jeffries and has, to date, clearly garnered the most interest of any of the agile approaches. XP preaches the values of community, simplicity, feedback, and courage and is defined, at least in part, by its 12 practices: the planning game, small releases, metaphor, simple design, refactoring, test-first development, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, and coding standards. There has been so much written about XPs practices that another rehash seems less important than discussing XPs impact on software development. The interest in XP generally comes from the bottom up, from developers and testers tired of burdensome processes, documentation, metrics, and formality. These individuals are not abandoning discipline, but excessive formality that is often mistaken for discipline. They are finding new ways to deliver high-quality software faster and more flexibly. XP and other agile approaches are forcing organizations to re-examine whether their processes are adding any value to their organizations. Well over 400 individuals have signed the Agile Software Development Manifesto Web page, available at: <www.agilealliance.com>. These individuals reaffirm their desire to deliver high-quality software without the burdens
A waterfall development life cycle, based on an assumption of a relatively stable business environment, becomes overwhelmed by high change. Planning is one of the most difficult concepts for engineers and managers to re-examine. For those raised on the science of reductionism (reducing everything to its component parts) and the near-religious belief that careful planning followed by rigorous engineering execution produces the desired results (we are in control), the idea that there is no way to do it right the first time remains foreign. The word plan, when used in most organizations, indicates a reasonably high degree of certainty about the desired result. The implicit and explicit goal of conformance to plan restricts a managers ability to steer the project in innovative directions. Speculation, the first conceptual concept, gives us room to explore, to make clear the realization that we are unsure and to deviate from plans without fear. It does not mean that planning is obsolete, just that planning is acknowledgeably tenuous. It means we have to keep delivery iterations short and encourage iteration. A team that speculates does not abandon planning; it acknowledges the reality of uncertainty. Speculation recognizes the uncertain nature of complex problems and encourages exploration and experimentation. We can finally admit that we do

Modularity. Cambridge: The MIT Press, 2000. 6. Beck, Kent, and Martin Fowler. Planning eXtreme Programming. Boston: Addison-Wesley, 2001.

COMING EVENTS

October 14-th Annual Pacific Northwest Software Quality Conference
1. This article is adapted from Jim Highsmiths book Agile Software Development Ecosystems. AddisonWesley, 2002. (Article quotes and examples taken from this book.) 2. For additional information, see James A. Highsmith. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York: Dorset House, 2000. 3. For extensive research in this area, see Buckingham, Marcus, and Curt Coffman. First, Break All the Rules: What the Worlds Greatest Managers Do Differently. New York: Simon & Schuster, 1999, and Buckingham, Marcus and Donald O. Clifton. Now, Discover Your Strengths. New York: Simon & Schuster, 2001. 4. The three tiers are Risk Leadership, Risk Entrepreneurship, and Lean Development. Portland, OR www.pnsqc.org November 3-Annual Amplifying Your Effectiveness (AYE) Conference 2002 Phoenix, AZ www.ayeconference.com
November 4-8 Software Testing Analysis and Review Conference Anaheim, CA www.sqe.com/starwest November 11-14 National Defense Industrial Association Denver, CO www.ndia.org November 18-21 International Conference on Software Process Improvement Washington, DC www.software-process-institute.com February 24-27, 2003 Software Engineering Process Group Conference

About the Author

Jim Highsmith is director of the Cutter Consortiums Agile Project Management Practice, author of Agile Software Development Ecosystems (2002) and Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (2000), and winner of the 2000 Jolt Award. He has more than 30 years experience as a consultant, software developer, manager, and writer. In the last 10 years, he has worked with information technology organizations, industrial product companies, and software companies in the United States, Europe, Canada, South Africa, Australia, Japan, India, and New Zealand to help them adapt to the accelerated pace of development in increasingly complex, uncertain environments.
Cutter Consortium 2288 North Coulter Drive Flagstaff, AZ 86004 Phone: (781) 648-8700 E-mail: jim@jimhighsmith.com
Boston, MA www.sei.cmu.edu/sepg/ April 28-May 1, 2003 Software Technology Conference 2003

References

1. Ambler, Scott. Agile Modeling. New York: John Wiley, 2002. 2. AgileAlliance. Agile Software Development Manifesto. 13 Feb. 2001 <www.agilemanifesto.org>. 3. Boehm, Barry. A Spiral Model of Software Development Enhancement. IEEE Computer May 1988. 4. DSDM Consortium. Dynamic Systems Development Method. Version 3. United Kingdom <www.dsdm.org>. 5. Baldwin, Carliss Y., and Kim B. Clark. Design Rules Vol. 1: The Power of
Salt Lake City, UT www.stc-online.org May 3-10, 2003 International Conference on Software Engineering Portland, OR www.icse-conferences.org/2003

Ten Principles

The following 10 principles have shown themselves useful in setting up and running projects. Most of these are known in the literature [3, 4, 8, 21]. My phrasing of them may be slightly different. 1. Different projects need different methodology trade-offs. 2. A little methodology does a lot of good; after that, weight is costly. 3. Larger teams need more communication elements. 4. Projects dealing with greater potential damage need more validation elements. 5. Formality, process, and documentation are not substitutes for discipline, skill, and understanding.
6. Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information. 7. Increased communication and feedback reduces the need for intermediate work products. 8. Concurrent and serial development exchange development cost for speed and flexibility. 9. Efficiency is expendable in non-bottleneck activities. 10. Sweet spots speed development. The first seven principles are discussed in this article, the last three will be addressed in part two. 1. Different Projects Need Different Methodology Trade-offs This should be obvious, but it seems to need re-stating at frequent intervals [15, 16, 17, 18]. Figure 1, adapted from Boehm and Port [8], shows one particular aspect of these differences. In this figure, the two diminishing curves show the potential damage to a project from not investing enough time and effort in planning. The two rising curves show the potential damage to the project from spending too much time and effort in planning. The lines crossing on the left indicate a project for which potential damage is relatively low with under-planning, and relatively high with over-planning. Much commercial software, including Web services fall into this category. The lines crossing on the right indicate a project for which potential damage is relatively high with under-planning, and for which much more planning would have to be done before damage would accrue from delays due to planning. Safety-critical software projects fall into this category. The curves should make it clear that when there is risk associated with taking a slow, deliberate approach to planning, then agile techniques are more appropriate. When there is risk associated with skipping planning or making mistakes with the plan, then a plan-driven approach is more appropriate. The curves illustrate clearly the home territory of each. Figure 2 shows a different characterization of project differences [3]. The hori-zontal axis captures the number of people needing to be coordinated, rising from one on the left to 1,000 on the right. The idea is that projects need more coordina-tion elements to their methodology as the number of people increases. The vertical axis captures the potential damage caused by undetected defects in the system, from loss of comfort to loss

WEB SITES

AgileAlliance
www.agilealliance.org/home The AgileAlliance is a nonprofit organization dedicated to promoting the concepts of agile software development, and helping organizations adopt those concepts, which are outlined by the Agile Software Development Manifesto and can be found on this Web site. The AgileAlliance was designed to be lightweight, initially consisting of a board of directors, one administrator, and a set of bylaws. Just like agile processes, all work and operations within the AgileAlliance is intended to emerge from subsets of members that self-organize into programs. Better communications and frequent deliveries communication reduce the need for intermediate work products. This site is a resource for people wanting to understand those ideas, to find more about improving skills and teaming, and to identify some project policies to use as a starting point. This site is set up as a museum of information, with exhibit halls, exhibit rooms, exhibits with notes, and a discussion area.
North Carolina State University
www.csc.ncsu.edu The North Carolina State University's (NCSUs) Computer Science Department cites strengths in the areas of software systems, communications and performance analysis, theory and algorithms, and computer architecture. Founded in 1967, NCSUs is one of the oldest computer science departments in the country and the only one at a state-assisted Research I University. The university hosts a small workshop, Agile Software Development Methodologies: Raising the Floor or Lowering the Ceiling at <http://collaboration.csc.ncsu. edu/agile>.
Agile Development Conference
http://agiledevelopmentconference.com The Agile Development Conference is a conference on delivering fit-for-purpose software under shifting conditions, using people as the magic ingredient. A number of techniques, practices, and processes have been identified to do this, and more will be found in the future. This conference will discuss people working together to create software, and the tools, techniques, practices, and issues involved. Come here to learn, or, even better, to name them. This conference has recently been funded and is still being organized. Read the conference vision and structure and the request for participation.

XBreed

www.xbreed.net/index.html XBreed is the product of mixing SCRUM, eXtreme Programming (XP) and Alexanderian ideas. Information technology is the result of developing multiple applications and shared components as fast as humanly possible. Combining Scrum and XP was very natural: Scrum provides a solid management framework, while XP provides a basic but complete set of engineering practices. The result is a lean but very effective way to run software projects. In addition, Scrum practiced at the application team level provided a shared resources team is involved can lead to re-usability. XBreed is a free method. This Web site includes everything you need to know to run XBreed projects.

Customer Collaboration Over Contracts
The degree of trust implicit in relying on customer collaboration rather than a contract is not justified in many customersupplier relationships. Even when the relationship begins with the best of intentions and the highest of expectations on both sides, one of the main difficulties in learning from experience is the use of unaided memory for coding, storing, and
however, mean they are easily realized. Selecting an appropriate balance point requires an open mind from both agile and plan-driven methodologists on both the supplier and customer sides of the equation.

Conclusions

Agile methodologies imply disciplined processes, even if the implementations differ in extreme ways from traditional software engineering and management practices; the extremism is intended to maximize the benefits of good practice [8]. The SW-CMM tells what to do in general terms, but does not say how to do it; agile methodologies provide a set of best practices that contain fairly specific how-to information an implementation model for a particular kind of environment. Even though agile methodologies may be compatible in principle with the discipline of models such as the CMM, the implementation of those methodologies must be aligned with the spirit of the agile philosophy and with the needs and interests of the customer and other stakeholders. Aligning the two in a government-contracting environment may be an insurmountable challenge. As we learn empirically what works well in the agile methodologies and how far they can be extended into different environments, we should expect software engineering to adapt and adopt the useful ideas of the visionaries in the agile movement. This will include using data to separate the wheat from the chaff as we identify what is
useful, and what is limited in its application. Laurie Ann Williams, for example, has integrated pair programming into an extension of the Personal Software ProcessSM called the Collaborative Software Process, and demonstrated that performance improves [9]. Many of the practices in the agile methodologies are good practices that should be thoughtfully considered for any environment. While the merits of any of these practices can be debated in comparison with other ways of dealing with the same issues, none of them should be arbitrarily rejected. Perhaps the biggest challenge in dealing effectively with both agile and plan-driven methodologies is dealing with extremists in both camps who refuse to keep an open mind.

18 CROSSTALK The Journal of
Odyssey and Other Code Science Success Stories
John Manzo AgileTek L.L.C. Code Science is an agile software development method based on eXtreme Programming (XP). This article describes the success achieved using code science to develop a complex industrial automation application. With a brief review of XP as background, code science is described in terms of refinements made to XP in applying it to a wide variety of application domains and industries over a period of almost four years. Included are real-world insights from the developers experience in applying this agile development method, concluding with a quantitative measure of the effectiveness of XP since its inception almost four years ago. sing Code Science, an agile software development methodology based on eXtreme Programming (XP), we1 recently delivered an application (code-named Odyssey) consisting of 400,000-plus executable source lines of code (ESLOC) to one of the worlds premier industrial automation companies. The application was written in C++ by as many as 17 developers (including some of our customers staff) in approximately 15 months. We are geographically remote from this customer. Odyssey was delivered a month and a half ahead of schedule with a productivity rate of 43 ESLOC per coding hour. During the project duration, approximately 2,400 defects were found and fixed, yielding a captured defect density of six defects per thousand lines of code (KLOC). During a thorough, more than six-week customer-conducted acceptance test, only about 200 defects were found (none severe), yielding a delivered defect density of 0.5/KLOC. The customer is delighted with the product and is confident of the competitive edge achieved.
In a side-by-side comparison of XP and waterfall on the very same project, the XP team delivered their final product when the other team was less than 50 percent complete. Since then, we refined our initial XP approach to encompass successive refinements that became known as Code Science.

In a side-by-side

comparison of XP and waterfall on the very same project, the XP team delivered their final product when the other team was less than 50 percent complete.
Code Science is largely based on the twelve tenets of XP. These are as follows: 1. Customer at the Center of the Project. The customer is treated as a full-fledged member of the development team with access to all the information that the rest of the team is privy to (e.g., defect logs, issue lists, etc.). 2. Small Releases. Simple releases are put into production early and updated frequently on a very short cycle (two to three days). New versions are released at the end of each iteration (three to five weeks). 3. Simple Design. A program built with XP should be the simplest program that meets the current requirements. 4. Relentless Testing. XP teams focus on validation of the software at all times. Programmers develop software by writing tests first followed by software that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that

team found it helpful to make their work environment homier. By making their workplace a more dorm-like environment, they significantly eased the stress of the long, often intense, workdays and nights.
Componetized Architecture
A high-level architecture was defined at the beginning of the first iteration, and as more information became available, more detail was added to successive iterations. Team leads would spend perhaps two days with their teams using white boards for a four to six-week iteration. We found that the biggest mistake one can make here is to attempt to get too detailed about something for which there is insufficient information.

Story Actors

Because most of the team never worked on an industrial automation application, actors helped the team get familiar with the clients domain. When the team took a field trip, they could identify the user types by their actor names (representative of their roleplay, more than their job title). It helped the team understand the business and how the product would be used in stories. The requirements were written in terms of how the system would be used, vs. desired functions. By associating who is doing what, it helps conceptualize and compartmentalize the functions.

Refactoring

Refactoring does not mean re-working. Do not partially write a feature with the intent of refactoring to get it complete later. Keep the changes simple, but keep them atomically complete.

Wall Gantts

Wall Gantts make load balancing easy and kept the project on track. The whole team sees the actual size of the function based on the task cards and there is great satisfaction in putting completion stickers on each card. An extremely useful management tool, Wall Gantts also helped to reveal issues and expose risks.

Pair Programming

Pair programming was especially useful in ramping up a new staff member. It was also quite useful for chasing down complex defects. For simple modules, the team found it more expedient to use the white board in pairs for 15 minutes, then program solo.

Large Team Experience

Although the overall team was divided into subteams, stand-up meetings were typically with the entire team. Team leads summarize and add detail with other team members as needed. As tasks are completed, people can move from one team to another.

The Small Organization Super Programmer Model
The communication of expectations in many small organizations is simple to describe. We refer to it as the super programmer model that implies a do-it-all expectation. The problem with this model is that, while expectations are clear, those expectations often lead to over-reliance on, and burnout of, individuals. We frequently find organizations that live by the super programmer model also live by the code-and-fix methodology. During the past few years, we have known colleagues who have given up the relative security of the large, established organization in favor of the increased opportunity afforded by small start-ups. Unfortunately, many have also found that the demands of the small start-up require great personal sacrifice. While some have returned to the more predictable large corporate environment, others have found increased job satisfaction through an alternative small-company model that is rapidly gaining in populariOctober 2002
budget. The software engineers were aware of the schedule and budget and felt ownership of it because they had participated in its development. On the other hand, in many large organizations, we have found that it is not uncommon for engineers to have little insight into the project schedule and budget. Upon first learning about XP, we found its code-focus to be difficult to accept. However, after observing an XP team in action, it left us with a different impression. The notion that programmers using XP do not design is a misunderstanding. One member of a small XP team explained it to us this way: Just because we focus on the code doesnt mean we dont give each task considerable forethought. We just dont write down the result formally, and we dont use a formal design tool. Then after he hesitated, he added, But we might draw a sequence diagram or two, if we think it might help. Another member of the same team said, We keep our designs as simple as possible, and we try not to spend any unnecessary time in design. We had an opportunity to witness the design process in action with a small team, and it reminded us of an informal brainstorming session you might see in any organization. The meeting had not been scheduled ahead of time. It just happened because one member of the team wanted some help. Within a few minutes, three team members had gathered around a white board, and 25 minutes later there was a design solution sketched out on the board. We suggested that someone capture the diagram more formally. Another interesting aspect of XP is pair programming. When we first heard about pair programming, we expressed agreement with the concept to a young client. Our thinking was that this technique would provide a backup in case one team member was pulled off the project or got sick. But the client was quick to explain that pair programming had nothing to do with having a backup. We have since learned that some pair programming team members are adamant about having both team members present side by side during 100 percent of the programming activity. That is right! Not only does it take two people to complete one program, but also if one of the two is missing, in some cases, the other does not want to move on. Doesnt that sound incredibly inefficient? But then the client went on to explain: Its the dialogue that I dont want to miss. By having my teammate right next to me,

eople go years, possibly their entire lives, exhibiting certain behaviors, sometimes knowingly but often unaware of any notable pattern. Sometimes an event will occur where a name is given to their particular behavior. A man who takes his work problems out on his family may be in an anger management class and be informed that he exhibits misplaced aggression. For a woman whose husband is an alcoholic, yet buys liquor for him, might be labeled an enabler. This identification can lead to an epiphany for the subject. This sudden realization is exactly what happened to me when a colleague of mine inquired as to my willingness to write this article on agile programming. I had never before heard the term agile programming, but my associate was familiar with the concept and also with my work, so I was willing to trust in his judgment. During research into the concept of agile programming, it quickly became evident that this was an acceptable label for the coding practices I have used routinely for more than 13 years.
Unwitting Agile Programmer
In my work as an analyst for a program management firm, I use a fourth generation language (4GL), control and analysis tool to build reports and graphs. My customers and I use these documents to perform analysis on schedule related data. The information derived from this data is used to point out past mistakes and potential problems, thus saving both time and money. This is my goal as a program management analyst, and the goal of my firm, to make our customers successful. Occasionally I am called upon to develop related applications or modules using 4GL. Some applications are written to analyze existing data and some to capture new data. The latest major development effort involved a resource-forecasting tool used to project future work requirements, and provide what-if scenario modeling. Because the customer wanted to keep the existing analysts at the site working on their current assignments, a separate contract was written and programmers were hired to per28 CROSSTALK The Journal of
form the work. This project followed a traditional software development methodology because this methodology worked for this project. The project finished on time and under budget. In 1994, the Air Force was awarded the Navy FA-18 programmed depot maintenance (PDM) contract. This was historic in that it was the first time that one branch of the armed forces was contracted to repair a weapon system used by a different branch. The accepted proposal called for the work to be performed at Hill Air Force Base (AFB) in Ogden, Utah. Since the fall of 1993, I had been working as a program analyst on the Programmed Depot Maintenance Support System contract in the Aircraft Directorate at Hill AFB. When the new workload arrived, the program management team provided precedence network schedules and tracked the work against the plan, as had been done for the other aircraft work at Hill AFB. Not long thereafter, the Aircraft Directorate was audited by an independent audit agency. Their findings required Hill AFB to provide an auditable unplanned work approval tracking system. The F-18s were brought to Hill AFB for a PDM, which is basically an overhaul of the entire aircraft, according to a specific set of operations to be performed, called planned operations. There are also provisions for problems encountered either during aircraft inspection or while the mechanics are performing planned work. These problems are defined as unplanned work and require extra time not accounted for in the planned operation package. Given that the FA-18 is a Navy weapon system and each aircraft has spent a good deal of time on aircraft carriers or at coastal Naval Air Stations, much of the unplanned work is corrosion removal. This unplanned work accounted for more than half of the total hours on a FA-18 PDM. The independent audit agency required a way to show that hours billed to this contract workload were not being used to work on F-16s or C-130s, which were located in the same hangars as the FA-18. Without such an auditable system, the

We met daily, but on an informal basis, usually with the point of contact (POC) most familiar with the section being worked in a one-on-one setting. This would almost always take place at the developers desk. We showed progress from the previous day and verified with the POC that their requirements were being met. Then we would identify any changes that needed to be made and start working to that end. As we moved through the development phase, we would identify those nice to have features and record those requirements for follow-on work. Through this process the programmer learned much more about his customers needs than he could by reading thousands of pages of requirements documents. It also showed a commitment to individuals and interactions over processes and tools. As changes were made to the application, corroboration was sought from the user before continuing further. Sometimes the user would sit through several iterations of code changes right at the programmers desk, commenting and critiquing. By working closely with the user community, there was very little need for documentation and training. By the time development was completed, the users had been trained through their constant involvement. There was no need for a formal training class after implementation. Since we knew there would be a good deal of follow-on changes, we decided to wait on documentation. The main application was completed with great success in plenty of time for the next audit. The only cost associated with the program was the temporary loss of productivity toward the original program management objectives. Our team was awarded a certificate of appreciation from the Aircraft Directorate citing a savings of 250 direct/indirect man-hours per aircraft. There was a dollar figure placed on both the cost (approximately $28,800) and the savings (approximately $1 million) resulting in an actual ROI of more than 30 to 1. Given the limited planning work, there was no way to predict such a fantastic windfall. However, had more time been spent in planning, documentation, contracting, and processes the ROI ratio would have been less impressive. Followon changes included expansion for both F16 and C-130 workloads, and a master writeup module that provided the users with a pick list of frequently used write-ups.
year before the workload was returned to the Navy, the use of this application on the F-16 and C-130 programs continues to this day. This program is still in a textual interface format but will soon be converted to an Oracle/Web-based format to provide better accessibility and ease of use. The user community has taken ownership of this application and they like it because of that very fact; it is their own creation. From time to time, minor bugs appear, which will be the case when omitting configuration management and strict coding practices, but the users are happy with that trade-off for flexibility. One might argue that agile software development flies in the face of program management. While the irony of a program management professional touting responding to change over following a plan is not lost on me, I see both methodologies coexisting and filling an important purpose: to make our customers successful. Yes, I am a proponent of agile programming but only in those cases where it is the best solution. Unless given a specific set of circumstances, I cannot say which is best. I have experienced success with both agile and traditional software development methodologies, and success is the ultimate goal.

1. AgileAlliance. Agile Software Development Manifesto. 13 Feb. 2001 <www.agilemanifesto.org>.
Gordon Sleve is a senior program analyst for Robbins Gioia LLC working in the ICBM program office at Hill Air Force Base (AFB) in Ogden, Utah. He was previously a site manager at Letterkenny Army Depot in Chambersberg, Penn. Sleve was selected as Robbins Gioias Senior Program Analyst of the Year for Dayton-based operations in 1995 for his support of the implementation of Programmed Depot Maintenance Support System at Hill AFB.
Robbins Gioia LLC OO-ALC/LMSO 6014 Dogwood Ave. Bldg. 1258 Rm. 14 Hill AFB, UT 84056-5816 Phone: (801) 775-5943 Fax: (801) 586-4835 E-mail: gordon.sleve@hill.af.mil
Specified Successful Use Continues
Although the F-18 contract only lasted one

Online Articles

Should You Be More Agile?
Rich McCabe and Michael Polen Software Productivity Consortium Agile software development techniques are an effective response to many problems still plaguing development projects. Although there are a number of issues to consider, almost any project can become more agile to its benefit. What exactly does it mean to be more agile? Words like predictable, cost-effective, and mature are more often used to characterize desirable software development processes. Agile development has come into focus recently due to the popularity of its most widely known interpretation, eXtreme Programming, but some of its foundations go back as far as 20 years. This article addresses some of the questions about agile: What is agile? Who needs to be agile? How can any project not creating small business applications seriously consider agile development? Is agile development an all or nothing proposition?
Agile Development: Weed or Wildflower?1
David Kane Steve Ornburn SRA International GBC Group, Inc. The Software Engineering Institutes Capability Maturity Model (CMM) has been a major force for software process and acquisition improvement in the federal governments civil and defense communities for the past decade. Major investments have been made by the government, their contractors, and many other organizations to make software development more consistent and reliable. The CMM provided an alternative to the cowboy programmer archetype. Amid this backdrop of progress, a new trend in software development has emerged agile development, which aims to build software faster and more flexibly than traditional approaches. Agile values individuals and interactions over processes and tools [1]. For organizations that have invested in a CMM, do agile methods represent the rebirth of the cowboy a weed to be stamped out? Or, are agile methods a reasonable way to build software in a world in which needs are changing at an ever-increasing pace a wildflower to be nurtured? This article looks at whether there is a home for agile methods in communities that have have embraced the CMM. Editors Note: Due to space constraints, CrossTalk was not able to publish these articles in their entirety. However, they can be viewed in this months issue on our Web site at <www.stsc.hill.af.mil/crosstalk> along with back issues of CrossTalk.