H. Bruce Allgood Deputy Director, Computer Resources Support Improvement Program
October 2002 www.stsc.hill.af.mil
What Is Agile Software Development?1
Jim Highsmith Cutter Consortium In the past two years, the ideas of agile software development, which encompasses individual methodologies such as Crystal methods, eXtreme Programming, feature-driven development, and adaptive software development, are being increasingly applied and are causing considerable debate. This article attempts to answer the fundamental question on many peoples minds: What is agile software development? ever do anything that is a waste of time and be prepared to wage long, tedious wars over this principle, said Michael OConnor, project manager at Trimble Navigation in Christchurch, New Zealand. This product group at Trimble is typical of the homegrown approach to agile software development methodologies. While interest in agile methodologies has blossomed in the past two years, its roots go back more than a decade. Teams using early versions of Scrum, Dynamic Systems Development Methodology (DSDM), and adaptive software development (ASD) were delivering successful projects in the early- to mid-1990s. This article attempts to answer the question, What constitutes agile software development? Because of the breadth of agile approaches and the people who practice them, this is not as easy a question to answer as one might expect. I will try to answer this question by first focusing on the sweet-spot problem domain for agile approaches. Then I will delve into the three dimensions that I refer to as agile ecosystems: barely sufficient methodology, collaborative values, and chaordic perspective. Finally, I will examine several of these agile ecosystems.
golly, we were successful because we followed our plan to the letter. Battlefields are messy, turbulent, uncertain, and full of change. No battlefield commander would say, If we just plan this battle long and hard enough, and put repeatable processes in place, we can eliminate change early in the battle and not have to deal with it later on. A growing number of software projects operate in the equivalent of a battle zone they are extreme projects. This is where agile approaches shine. Project teams operating in this zone attempt to utilize leading or bleeding-edge technolo-

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

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

The Future of Agile Development
There are fundamental shifts driving economies, the structure of products that we build, and the nature of the processes we use to build products. These changes in products, technologies, firms, and markets are not a passing phenomenon, according to Carliss Baldwin, Harvard Business School professor and Kim Clark, dean of the Harvard Business School faculty. These fundamental changes driven by powerful forces deep in the economic system, forces which moreover have been at work for many years. we must be prepared to dig deep, for the forces that matter are rooted in the very nature of things, and in the processes used to create them. [5] In the foreword to Planning eXtreme Programming, Tom DeMarco makes the analogy between military history and software development as each swing from the relative advantages of armor to those of mobility. DeMarco says: In the field of IT, we are just emerging from a time in which armor (process) has been king. And now we are moving into a time when only mobility matters. [6] Agile development is not defined by a small set of practices and techniques. Agile development defines a strategic capability, a capability to create and respond to change, a capability to balance flexibility and structure, a capability to draw creativity and innovation out of a development team, and a capability to lead organizations through turbulence and uncertainty. Agile development does not abandon structure, but attempts to balance flexibility and structure trying to figure out that delicate balance between chaos and rigidity. The greater the uncertainty, the faster the pace of change, and the lower the probability that success will be found in structure. Plan-driven methodologies have a definite place for some problem domains just as individual practices (configuration management for example) have a definite place in the most agile of software development projects. In a less volatile era, rigorous processes were applicable for a wide range of projects. In an era in which traditional management styles dominated, plan-driven software developOctober 2002
ment approaches fit well. But as Bob Dylan sang, Times, they are a-changin. Volatility and uncertainty increasingly defines todays business, and even todays military environment. Talented technical people want to work in an organization in which they have more control over how they work and how they interact with peers, customers, and management. Problems are changing, people are changing, and ideas are changing. While there are still opportunities for plan-driven style development and management, I believe growth lies in being agile and flexible. Throughout the last three years, I have used agile methods with project teams in India, Canada, Norway, the United States, New Zealand, Poland, and Australia. Companies in these countries are struggling with exploratory projects that run the gamut, including an e-commerce infrastructure product, a clinical drug-trial monitoring application, 300,000 lines of embedded C code in a new cell-phone chip, a worldwide financial system product, a myriad of internal IT applications, the complete business system for a dotcom start-up (that is still in business), and an oil-field geophysical data gathering and analysis system. These companies want to be more agile: They want to create change for their competitors and respond quickly to market conditions. They plan, but they are not blinded by those plans. They focus on delivering customer value, not adding up how many processes they have in place. They document, but they do not get lost in piles of paper. They rough out blueprints (models), but they concentrate on creating working software. They focus on individuals and their skills and on the intense interaction of development team members among themselves and with customers and management. They deliver results in a turbulent, messy, ever-changing, ever-exciting marketplace.

Salt Lake City, UT www.stc-online.org May 3-10, 2003 International Conference on Software Engineering Portland, OR www.icse-conferences.org/2003
Learning From Agile Software Development Part One
Alistair Cockburn Humans and Technology This two-part article compares agile, plan-driven, and cost-sensitive software development approaches based on a set of project organization principles, extracting from them ideas for pulling agile techniques into cost- and plan-driven projects. Part one describes how agile and plan-driven teams make different trade-offs of money for information or for flexibility, and presents the first seven of 10 principles for tuning a project to meet various priorities, including cost, correctness, predictability, speed, and agility. Part two, which will run in the November issue of CrossTalk, will present the last three principles, then pull the material together for actions that plan-driven and cost-sensitive project teams can use to improve their strategies and hedge against surprises.
eing agile is a declaration of prioritizing for project maneuverability with respect to shifting requirements, shifting technology, and a shifting understanding of the situation. Other priorities that might override agility include predictability, cost, schedule, process-accreditation, or use of specific tools. Most managers run a portfolio of projects having a mix of those priorities. They need to prioritize agility, predictability, and cost sensitivity in varying amounts and therefore need to mix strategies. This article focuses on borrowing ideas from the agile suite to fit the needs of plan-driven and cost-sensitive programs. Our industry now has enough information to sensibly discuss such blending. The agile voices have been heard [1, 2, 3, 4, 5, 6, 7], the engineering voices have been heard [8, 9, 10], two articles in this issue [11, 12] illustrate the differences in world view, and some authors have discussed the question of their coexistence and principles underlying successful development strategies [3, 8, 13].
MFF propositions, and how best to allocate resources for each. Predictable issues can be investigated using breakdown techniques. Such an issue might be creating a schedule for work similar to that successfully performed in the past. Unpredictable but resolvable issues can be investigated through study techniques such as prototypes and simulators. Such issues include system performance limits. These are also MFI propositions. Agile and plan-driven teams are likely to use similar strategies for these issues as part of basic project risk management.
This is a MFI [moneyfor-information] situation: It is worth spending a lot of money now to discover. where those next defects are located.
Unresolvable issues tend to be sociological, such as which upcoming standard will gain market acceptance, or how long key employees will stay around. These issues cannot be resolved in advance, and so are not MFI propositions, but are MFF propositions. Agile and plan-driven teams are intrinsically likely to use different strategies for these issues. Agile teams will set up to absorb these changes, while plandriven project teams must, by definition, create plans for them. Teams will differ on which issues are resolvable, and how much money should be spent in advance on predictable issues. A plan-driven team is more likely to decide that creating the project plan is basically a predictable issue, and that a good MFI strategy is to spend resources

are largely outside the focus of the agile methodologies, but they are arguably crucial for their successful adoption. Over-documentation is a pernicious problem in the software industry, especially in Department of Defense (DoD) projects. Software maintainers have long known that the only documentation you can really trust is the code (and those of us with experience debugging compiler and run-time defects doubt even that). Having said that, an architectural description of the system that provides a tour of the top-level design can be invaluable to maintainers. From a technical perspective, as projects become larger, emphasizing a good architectural philosophy becomes increasingly critical to project success. Major investment in the design of the products architecture is one of the practices that characterizes successful Internet companies [4]. Architecture-based design, designing for change, refactoring, and similar design philosophies emphasize the need for dealing with change in a systematic fashion. One of the compromises that agile methodologists are likely to be required to make as they move into larger projects and applications that are life- or missioncritical is a stronger emphasis on documenting the architecture and the design of the system. In turn, plan-driven methodologists must acknowledge that keeping documentation to a minimum, useful set is also necessary. What benefit do we really get from detailed designs where the programming design language is nearly as large as the code? Much of the controversy with respect to the technical issues centers on what happens as projects scale up. Practices that rely on tacit knowledge and highly competent professionals may break down in larger teams with their rapidly expanding communication channels and coordination challenges. However, replacing those practices with ones appropriate for large teams may result in losing the emergent properties of the agile methodology.
retrieving outcome information [5], with the consequence that change can make liars of us, liars to ourselves [6]. As time goes by, as things change, our unaided memories become unreliable. The reliance of agile methodologies on tacit knowledge is therefore vulnerable to perception shifts over time, yet tacit knowledge may be much more effective than external, explicit knowledge in setting expectations and driving behavior. In a government-contracting context, federal acquisition regulations establish a context for ensuring fair play even if it is not necessarily an effective and efficient environment. This can be considered a problem in expectations management. The agile methodologies manage customer expectations by insisting on an ongoing customer interaction and rapid iteration.

Responding to Change Over Planning
Dwight Eisenhower is quoted as saying that planning is more important than the plan. And one of the great military axioms is that no battle plan survives contact with the enemy. That said, planning and preparation are prerequisites to success. Planning for change is quite different from not planning at all. Agile methodologies, with their rapid iterations, require continual planning. Customer collaboration and responsiveness to change are tightly linked, if perhaps inconsistent with typical government-contractor relationships. One of the shifts in acquisition strategy in recent years has been toward prototyping, evolutionary development, and risk-driven life cycles. With their emphasis on addressing requirements volatility, agile methodologies could be a powerful synthesis of practices that DoD contractors could leverage to make planning more responsive to change.

One of the most

significant barriers to implementing an agile methodology is likely to be an inability to establish and maintain close and effective customer collaboration.
Ignoring possible regulatory issues, the stories in XP, in conjunction with an evolutionary life cycle and ongoing customersupplier communication [7], document requirements and commitments in a manner that could satisfy the goals of requirements management and software project planning in the SW-CMM. Will such a set of stories satisfy a DoD customer that the requirements are adequately stated and that commitments as driven by the customer are being met? Or will the natural desire for a more comprehensive requirements statement drive the customer towards a requirements specification that lacks the dynamic capability desired for an agile methodology? Perhaps an honest answer to this type of question reveals more about the comfort levels of both customer and supplier in an agile relationship. One of the most significant barriers to implementing an agile methodology is likely to be an inability to establish and maintain close and effective customer collaboration and this barrier is likely to be erected on the customers side of the relationship.

Stepping Up to the Plate

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.

6. 7. 8. 9.

Persistence of the Illusion of Validity. Psychological Review 85.3 (1978). Dawes, Robyn M. Rational Choice in an Uncertain World. Orlando: Harcourt Brace Jovanovich, 1988. Beck, Kent. eXtreme Programming Explained: Embrace Change. Boston: Addison-Wesley, 1999. Paulk, Mark C. Extreme Programming From a CMM Perspective. IEEE Software 34.11 (2001). Williams, Laurie Ann. The Collaborative Software Process. Diss. University of Utah, Aug. 2000.
Mark C. Paulk is a senior member of the Technical Staff at the Software Engineering Institute. He has been with the SEI since 1987. Paulk was the book boss for Version 1.0 of the Capability Maturity Model for Software and the project leader during the development of Software CMM Version 1.1. His current interests center on high maturity practices and statistical control for software processes.
Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Phone: (412) 268-5794 Fax: (412) 268-5758 E-mail: mcp@sei.cmu.edu
1. Paulk, Mark C., Charles V. Weber, Bill Curtis, and Mary Beth Chrissis. The Capability Maturity Model : Guidelines for Improving the Software Process. Boston: Addison-Wesley, 1995. 2. Boehm, Barry. Get Ready for Agile Methods, With Care. IEEE Computer Jan. 2002. 3. Paulk, Mark C. Using the Software CMM with Good Judgment. ASQ Software Quality Professional June 1999. 4. MacCormack, Alan. Product Development Practices That Work: How Internet Companies Build Software. MIT Sloan Management Review Winter 2001. 5. Einhorn, Hillel J., and Robin M. Hogarth. Confidence in Judgment:
Personal Software Process is a service mark of Carnegie Mellon University.
2002 U.S. Government's Top 5 Quality Software Projects
The Department of Defense and CrossTalk are currently accepting nominations for the 2002 U.S. Government's Top 5 Quality Software Projects. Outstanding performance of software teams will be recognized and best practices promoted. These prestigious awards are sponsored by the Office of the Under Secretary of Defense for Acquisition Resources and Analysis, and are aimed at honoring the best of our government software capabilities and recognizing excellence in software development. The deadline for the 2002 nominations is December 13, 2002. You can review the nomination and selection process, scoring criteria, and nomination criteria by visiting our Web site. Then, using the nomination form, submit your project for consideration for this prominent award. Winners will be presented with their award at the 15th annual Software Technology Conference in Salt Lake City and will be featured in the July 2003 issue of CrossTalk and recognized at the Amplifying Your Effectiveness 2003 conference.

The Application

The Odyssey program consists of two distinct but related scalable vector graphics applications. The first is a run-time application that issues real-time commands from a touch screen panel to devices known as programmable logic controllers, which are used in manufacturing assembly processes. The second is a panel design application that enables human-machine interface engineers to develop the graphical equivalent of a hardware panel made up of buttons, gauges, and other control and monitoring devices.

Why Agile Methods

We began experimenting with XP several years ago, and actually began our first XP project a few months before Kent Beck published his first book on the subject [1]. Before that time, we used several traditional waterfall and rapid application design-based methods. We were impressed at how quickly our first XP project was completed.
the features they need are provided. 5. Refactoring. The system design is improved throughout the entire development process. This is done by keeping the software clean, without duplication, as simple as possible, and yet complete ready for any change that comes along. (Martin Fowler defines refactoring as the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure [2]). 6. Pair Programming. XP programmers write all production code in pairs: Two programmers work together at one machine. 7. Collective Ownership. All the code belongs to the all the programmers. This enables the team to work at full speed. When something needs changing, it can be changed without delay. It is important to note that an effective configuration management discipline is an important enabler of this practice. 8. Continuous Integration. The software system is integrated and built multiple times per day (ideally, every time a task is finished). Continual regression testing prevents functional regressions when requirements change. This also keeps the programmers on the same page and enables very rapid progress. 9. 40-Hour Workweek. Tired programmers make more mistakes. XP teams do not work excessive overtime, which keeps them fresh, healthy, and effective. 10. On-Site Customer. An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions. 11. Coding Standards. For a team to work effectively in pairs and to share ownership of all the code, programmers need to write the code in the same way with rules that ensure the code communicates clearly. 12. Metaphor. Development is guided with a

Code Science is registered in the U.S. Patent and Trademark Office. www.stsc.hill.af.mil
simple shared story of how the overall system works. XP was originally used to develop a payroll program at Chrysler Corporation [3]. The team used the metaphor of an assembly line to describe the process of building a payroll check. The key tenet in XP is iterative development and the unforgiving honesty of working code. The concept of iterative development has been around for a long time. However, XP does have some limitations such as scaling the ability to add large numbers of developers to a project that requires them. (Most XP practitioners consider six to 12 developers to be the practical limit.) It was necessary to modify XP to develop a methodology that would work on large projects, across multiple application domains, and for clients with diverse and sometimes very specialized needs, for example, regulatory environments such as the Food and Drug Administration (FDA), where there is a strong need for extensive documentation.
cessive rounds (usually three) until the standard deviation (a measure of uncertainty) is made sufficiently narrow. Once the number of perfect programmer hours is known, a loading factor is applied to convert this estimate to real programmer hours. + Componentized Architecture For complex systems, it is especially important to assure conceptual integrity in the final product. Also, because complex systems can be large, it is also important to enable the system to be developed in an environment of distributed ownership. Among the least understood areas of XP is the notion of design-as-you-go through refactoring. To some, especially those who equate design and architecture, this means no up-front architecture, and, by implication, any architecture that the delivered system may have is a defacto one at best.
By spending a relatively small amount of time up front, one can ensure both a product with conceptual integrity and a project that can scale. + Automated Contract and Regression Testing Given that XP is premised upon the need to embrace change, making it easy to perform regression testing is an important part of any XP project. We have taken this to the next level by implementing the capability to perform contract testing, which checks for the existence of predefined pre-conditions, post-conditions and class invariants. (As an example, an overdrawn flag in your checking account is invalid if there is a positive balance remaining after the last transaction.) + Story Actors We have added to the notion of stories the concept of story actors. Actors are personifications of the various categories of users the system will encounter. Thinking of the requirements in terms of actors brings the requirements to life as well as unmasks nuances that would otherwise remain invisible to both the developers and the customer. + Wall Gantts Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project. We have taken the concept one step further and adapted it to agile methods by creating a physical construct using twine, pushpins, and index cards. The twine is used to create a line on a wall. Tasks, written on cards, are folded in half and hung on the line (one line for each project participant). Index cards with dates (one for each day of an iteration, which usually lasts three to five weeks) are pinned across the top of the chart. Physically constructing the Gantt chart makes it very easy to move tasks around, drive out dependencies, and load balance. Because the chart is wall size, it is easy for the team to stand around the chart to discuss the state of the project in near real-time (each day starts with a stand-up meeting). The wall Gantt also provides clear ownership for development efforts, encourages accountability, and serves as the teams war room and center of the project universe. + Automatic Document Generation Through a tool we have built called Doc-It (similar to JavaDoc), we are able to reduce the burden and streamline the process of generating documentation that describes the inner workings of the code. Experience shows that it is a poor practice to separate

Conclusion

During a period of almost four years, XP/Code Science has been employed on 14 projects across a wide variety of application domains and industries such as aerospace, telecommunications, banking and finance, pharmaceuticals, consumer goods, and even pari-mutuels. These projects ranged in size from 10 KLOCs for a Personal Data Assistant client, to more than 400 KLOCs

CONTINUED ON PAGE 30

Application to Odyssey
Code Science is used on all Geneer software development projects. The Odyssey project was no exception. However, no two projects are the same. Each emphasizes certain of the specific tenets described above to differing degrees. In the interest of brevity, we

40-Hour Week

During a long period of peak activity, the
Software Engineering Technology
Integrating Systems and Software Engineering: What Can Large Organizations Learn From Small Start-Ups?
Paul E. McMahon PEM Systems In an effort to integrate more effective systems and software engineering, many companies today are examining their internal processes. Recent research conducted on distributed development efforts may provide insight that could aid todays systems and software integration initiatives. Drawing material from his book, Virtual Project Management: Software Solutions for Today and the Future [1], the author explores variations in large and small engineering organizations and presents an alternative view of large projects that may aid companies in their quest for more effective systems and software integration.
oday, many companies are examining their internal processes in an effort to integrate more effective systems and software engineering. Many of the challenges faced in integrating systems and software engineering exhibit similarities to challenges observed on large distributed efforts. In this article, engineering organizational variations are first explored, not to judge but to recognize the existence of variation and to note a common characteristic observed in all successful organizations regardless of size or structure. The article then discusses how the identified characteristic is achieved in different organizations. This preliminary investigation sets the stage for a closer examination of what systems and software integration means in practice. An alternative view of a successful large project is presented that may challenge current published literature. The information presented in this article is the result of research initially conducted on large distributed projects [1].
the Systems Engineering department is totally responsible for producing the software requirements specification (SRS). In other organizations, the Systems and Software Engineering departments collaborate on the production of the SRS with each producing specific piece-parts of the final SRS. We have also witnessed a third organizational variation where the Software Engineering department produces the complete SRS, while the systems group provides a review and approval role.

CONTINUED FROM PAGE 21

for the industrial automation project described herein. The languages were mostly C++ but also included C, HTML, VB, and SQL. Productivity ranged from a low of 21 to a high of 48 lines of code per coding hour, averaging 35 lines of code per coding hour. Compared to projects conducted before adopting this intensely practical and agile software development discipline, our cost per line of code and defect rates were drastically reduced while our development velocity was significantly increased. Our most recent audit revealed an overall average productivity index of 22 [4]. This index is a management scale corresponding to the overall process productivity achieved by an organization during the main software build. An index of 25 is considered among the highest ever recorded. Code. Boston: Addison-Wesley, 1999. 3. C3 Team. Chrysler Goes to Extremes. Distributed Computing. Oct. 1998 <www.xprogramming.com/public ations/distributed-computing.html>. 4. Putnam, Lawrence H., and Ware Myers. Measures of Excellence: Reliable Software on Time, Within Budget. Upper Saddle River: Prentice Hall/Yourdon Press, 1992.
1. We as mentioned throughout this article refers to the Geneer company.
John Manzo has spent more than three decades of his career in software engineering, and has contributed to and made significant accomplishments in the development of software, computer, and telecommunications solutions. Manzo comes to AgileTek from Geneer where he was chief technology officer, and brings with him a legacy of broad and deep experience in agile development methods. Earlier in his career, Manzo was recognized for his development of the Fire Control software for the Navy's highly successful AEGIS system one of the largest and most complex software developments ever delivered to the Department of Defense. He has served as a representative to the President's National Science Advisory Board, and served as an adjunct faculty member of Harvard University where he developed, and for several years taught, The Management of Software Engineering.