HOME
REGISTRATION
Conference Schedule
Student Volunteers
TRACKS
APM & Testing
Tutorials
Workshops/P2P
Research Papers
Experience Reports
Educators Symposium
Open Space
Intro to Agile
Executive Summit
Invited Talks
Vendor Presentions
CONFERENCE SPONSORS
EVENT ORGANIZERS
DENVER INFO
PRESS RELEASE
SUBMISSION FORMATTING DETAILS
INFORMATION FOR PRESENTERS
PAST CONFERENCES
ADC 2004
XPAU 2004

Conference Wiki

Conference Presented By:


Subscribe to RSS Feed
(version 0.9)

Website Hosted By:

Experience Reports
Tuesday AM July 26, 2005
Experience reports contain first-hand information and reflection: "We saw this, did that, and consider this-and-that about our experiences." Attending experience report sessions is a great way to glean information from practicing agile developers and managers. Each report recounts a compelling story about putting agile practices to work. Reports cover a wide range of topics including: effective teamwork and project management practices; agility and user interaction, API, and database design; agile testing and QA experiences; agility and offshore and distributed teams; agility and CMMI; and injecting agile practices into traditionally inflexible organizations.
Agile Development of the Database:
A Focal Entity Prototyping Approach
   
Tuesday July 26, 2005 Morning
PowerPoint Presentation  
Roy I. Morien, Curtin University of Technology      
Abstract: The agile development of the database and the application system is a highly productive and successful activity when undertaken in a coherent and organized manner. Agility does not preclude structure and order in development. The more serial thinking that the entire database schema must be developed once and for all, and before any processing development can take place, is seen to be incorrect and unnecessary. The evolution of the database, like other aspects of evolutionary and agile development of software systems, contributes significantly to schema quality, correctness and adaptability.
This paper draws upon 20 years of experience in developing database systems in an agile, evolutionary manner, and suggests and elaborates upon a well ordered and well-organized, but clearly agile approach, to database development, which the author has termed "Focal Entity Prototyping". This technique takes a domain/conceptual modeling approach supported by user interface prototyping which then drives development. Research and experience in both commercial development and in an academic project environment has demonstrated the reasonableness and efficacy of this approach.

Teaching a Goliath to Fly
Applying agile methodologies in a large legacy codebase
   
Tuesday July 26, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
Salim Nair, Primavera Systems
Prasad Ramnath, Primavera Systems
     
Abstract: When Primavera Systems decided to adopt agile methodologies for the development of their Project management suite, no one expected it to be easy. There were about 1.5 M lines of legacy code, in Delphi and Java, several applications, tight release cycles, high demand from marketing for new features. This paper describes from a software-architecture perspective, the transformation of a largely waterfall-based development strategy into an agile, test-driven practice.. It looks at the obstacles and difficulties we faced during this change, the way we approached refactoring legacy code to make it testable. It also looks at the process of creating a Business Object Framework in an evolutionary way to support our test driven development.

Challenges of Delivering APIs in an Agile Context    
Tuesday July 26, 2005 Morning
XR3  
John Major      
Abstract: "Platform" technology should be stable, and the APIs that express them are normally expected to be un-responsive to change. But in a rapidly changing domain (biotechnology) in a churning business environment, the challenges of providing useful, well-designed APIs rapidly mount. How often will other teams pick up new versions of libraries? How do you manage rapid database schema evolution? How does a business organization get significant code reuse when the concepts are changing rapidly, harvesting common features from the work of teams using the APIs? What are the Really Big Mistakes that this team made that others in the same situation could avoid? Encounters with Big Design Up Front are described, as well as successes with incremental delivery to projects taking frequent releases of the APIs. Team management issues and testing challenges are also discussed, with a few figures about number of automated tests, KLOC and code coverage provided.

Promiscuous Pairing and
Beginner's Mind: Embrace Inexperience
   
Tuesday July 26, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
Arlo Belshee, Critical Path Software      
Abstract: On an 18-month project that grew from 3 to 11 people, team members conducted many experiments with task ownership, pair swap frequency, and task assignment methods.
We experimented with the optimal time between pair swaps. We conducted a dozen week-long experiments in which we required pairs to switch at specific times, ranging from 30 minutes to one week. We also experimented with swapping at will, or on task completion. We found that fixed 90 minute swaps had the best impact on our velocity.
We also experimented with varying levels of task ownership. We gathered a half-dozen data points as follows. One data point was completely ad-hoc; every time that a pair formed, it would take an arbitrary task from the board. Another point was individual ownership; each person owned a set of tasks for the week, and would pick one or more sequential partners with whom to work on them. The remainder of the points were station-owned tasks; a task would stay at a station, and each pair swap would move one partner off the station and leave the other. The variance between these points was in the number of swaps for which a single person remained. Optimal velocity resulted from station-owned tasks with alternating pair swaps.
Finally, we tried several methods of task assignment. Here, we tested two independent variables. The first variable was pull- or push-based task assignment. The second was how to take into account knowledge in an area when assigning tasks in that area. The three values were to favor local knowledge, disfavor local knowledge, or assign randomly. Pull-based assignment disfavoring local knowledge resulted in maximal velocity. Additionally, we found that making this task assignment the key task for our 2+ daily launch meetings provided a clear, concise purpose for those meetings. This kept the meetings at less than 5 minutes, even for an 11 person team.
Overall, we found this promiscuous pairing to greatly increase the flow of information through pair net. In addition to increasing our velocity and reducing the number of 15 minute or longer refactorings we needed per week, it dramatically decreased our new hire ramp-up time. We were able to fully ramp up new hires who had never programmed in C++ before - to the level that they could write template metaprograms and train the next round of new hires - in one month.

Estimating in actual time    
Tuesday July 26, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
Moses Hohman, Northwestern University      
Abstract: I present a proposal for an experience report that describes my team's experiences with an estimation scheme that avoids the confusing notion of "ideal" time, uses an appropriate level of granularity for the size of the story, and which acknowledges the uncertainty inherent in estimation. I will describe the scheme, and then will present what we've learned using the scheme, both from a process point of view and from an empirical, data mining point of view.

Improving Agile Team Learning
by Improving Team Reflections
   
Tuesday July 26, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
Marilyn Lamoreux, Medtronic, Inc.      
Abstract: Many Agile proponents encourage reflection as part of the feedback/learning cycle. When we began using Agile practices, including reflection, I discovered that our organization's norms and beliefs tended to discount the value of regular reflection meetings. Many engineers wanted to avoid anything that might be seen as "touchy-feely." Our initial attempts at holding regular reflection meetings for agile teams had mixed results. Some reflections turned into gripe sessions where a lot of venting occurred but nothing changed. Other reflections were short and a little too sweet - team members said little and no learning occurred. This paper describes some of our efforts helping teams improve their reflection meetings and relates some of the positive results in my organization as a result of regular reflection. It also discusses techniques for overcoming initial reluctance to take time out to reflect, keeping reflection meetings interesting, and taking reflection to a deeper level.

Experience Reports
Tuesday PM July 26, 2005
Introducing Agile Development (XP)
into a Corporate Webmaster Environment
   
Tuesday July 26, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Matt Ganis, IBM, David Leip, IBM
Joe Bergin, Pace University, Fred Grossman, Pace University
     
Abstract: In November of 2004, the IBM Corporate Webmaster team deployed a major release of their corporate web portal (www.ibm.com). This effort required the updating of over 1.6 million webpages in support of 9 countries/languages and required the coordination of hundreds of programmers/information architects spanning 4 continents. While the release addressed many facets of the site, including layouts, and style changes, new functions were developed, for the first time, using agile techniques. In this paper we present an experience report of our development efforts, which utilized extreme programming (XP).
We will focus on the challenge of moving a large, traditional waterfall-driven organization to an agile development methodology. In particular, we address the challenges and value of adhering to the full set of XP practices, some of which we found (at times) difficult to follow.
Among the challenges we faced during the project and that were reconfirmed during the project retrospectives were:
* doing agile development in an organization that interfaces with and depends upon non-agile organizational entities
* meshing agile development cycles with infrastructure changes that often happen on different timelines.
* doing test driven development in an organization that typically depends on a separate test and quality assurance teams distributed around the world and function according to separate quality assurance cycles outside the scope of the development team
* assessing the need for and effecting education and culture change as an important factor in the success of an agile project.
Other environmental issues that will be discussed included coping with and providing for I/T organizations that require advance notification of specifications for the deployment of applications in datacenters. This proved to be especially challenging in an environment where a change in the requirements can cause issues with application deployment and infrastructure setup such as firewalls and secure data communication paths.
Overall we report a positive (although challenging) experience with the XP methodology, and we will report on how we plan to modify/augment some of the practices and perhaps the environment for future agile project development.

Staying agile in Government Software Projects    
Tuesday July 26, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Barg Upender, SRA International      
Abstract: Can government software projects be agile? What do Scrum and XP practices have to offer in this regulated and highly political environment? In this experience report, we will discuss some of the unique challenges in our environment and how we have had to adapt these practices to produce commercial-grade software. First, we will provide a "report card" on our progress in applying Scrum & XP practices to a clinical data management project over a two year period. Then, we will describe the practices that were accepted "religiously", adapted to get the job done, and completely abandoned. In particular, we will discuss how we got around bootstrapping, Rational tools, documentation needs, and managing a product backlog for a diverse, decentralized user community. In addition, we found that staying agile is just as hard as becoming agile. Putting agile practices to work, although a challenge, resulted in better team communication, more usable system, and improved partnership between the users and the development team.

Selling Agile:Target Cost Contracts    
Tuesday July 26, 2005 Afternoon
Full Text PDF File  
Bruce Eckfeldt, Cyrus Innovation
Rex Madden, Cyrus Innovation
John Horowitz, Esq., Grotta, Glassman & Hoffman
     
Abstract: Agile approaches make a lot of sense to software developers, but selling Agile to business people can be a tricky task, particularly in a consulting situation. It is not difficult to get people to appreciate the benefits of Agile, but forming an agreement that embraces change is not simple. Target-Cost contracts have been suggested as a solution to structuring agile projects, but do they work? This experience report describes how we have successfully used them with three different clients. This approach has allowed us to build better client relationships by ensuring that contracts empower both the development team and the client to work collaboratively to deliver software that meets the client's real needs. We believe these experiences will add value to teams working in both a formal consulting environments as well as an internal development department.

Community Building:
a Critical Success Factor for XP Projects
   
Tuesday July 26, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Gil Broza, Industrial Logic      
Abstract: Extreme Programming (XP) literature and discussions often view successful projects only as customer-driven product development: planning, coding and testing an unfolding series of prioritized units of vertical functionality. I claim, however, that a successful project also requires a prospering community, comprising an introspective group of committed professionals communicating effectively, and using a well-understood, stable process. Weakness on any of these fronts presents a high risk of failure; therefore, I advise every XP project's members to actively engage in building their community, such that it reaches its critical level of development already by the first internal release. To help in this endeavor, I provide a comprehensive list of activities and attitudes, to practice and avoid, during the first release's time.

Using Open Spaces to Resolve Cross Team Issues    
Tuesday July 26, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Constance M. Tartaglia
Primavera Systems, Inc.
     
Abstract: Cross-team development issues that need special coordination and close attention can be managed successfully by using the Agile concept of "Open Spaces". During our 5.0 development cycle, which is being executed by ten teams in 16 sprints, we use open spaces to identify and evolve critical cross team issues. A concept we wished to emphasize during this development cycle is that of self managed teams. The open space fits very well with that concept. As with other new agile tools, adaptation began slowly, but once developers realized that the decision-making power belongs to the open space participants, the popularity of this tool increased.

A False Measure of Success    
Tuesday July 26, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Richard K Cheng, Level One Consulting      
Abstract: This experience report examines the changes in workflow and processes for the web development teams at a major US financial market and the results thereof. The workflow and practices of these web development teams, though not perfect, did satisfy the teams' internal business customer. These customers were pleased in the rapid turn-around time these technology teams provided. Any issues or defects that had occurred were within acceptable tolerances for the customer's business needs. However, the management teams of the technology division mandated implementation of processes to ensure stability, redundancy, and uptime. Employee goals, and financial bonus, were updated to measure qualities such as 99.99% uptime, full redundancy and zero defects. As the development teams came closer to their technology goals, the cost of running these projects increased and project turn around time decreased. Defining "What quality level is acceptable" and "What cost is acceptable" was shifted from the Business teams to the Technology teams. The business customers were no longer pleased with the performance of their technology counterparts, thus creating A False Measure of Success.

Experience Reports
Wednesday AM July 27, 2005
Formalizing Agility:
An Agile Organization's Journey toward CMMI Accreditation
   
Wednesday July 28, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
Steven W. Baker, DTE Energy, Detroit, Michigan      
Abstract: Agile methods are quite compatible with formal process improvement frameworks. Rather than casting discipline and documentation to the wind, agile methods, when seriously applied, are actually very focused and comprehensive. Likewise, a framework such as the SEI Capability Maturity Model Integrated (CMMI) need not be an overwhelming excess of paperwork and bureaucracy; when appropriately implemented, the CMMI encourages and enables significant and sustainable improvements.
This report describes the ongoing journey of DTE Energy's large IT organization in realizing agility and process improvement in a Fortune 300 corporation. From following waterfall-based approaches to embracing agile methods, and from early attempts with the CMM to a renewed commitment to continuous improvement by adopting the CMMI, it explores cultural and organizational changes that enable real-world process improvements.

Stretching Agile to fit CMMI Level 3:
the story of creating MSF for CMMI Process Improvement
at Microsoft Corporation
   
Wednesday July 27, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
David J. Anderson, Microsoft Corporation      
Abstract: Agile practitioners pride themselves on their productivity, their agility, the low ceremony, lightweight, tactic knowledge processes with no waste, adaptive planning and frequent iterative delivery of value. It is often assumed that CMMI compliant process need to be heavyweight, bureaucratic, slow moving, high ceremony and plan driven. Agile developers perceive formal process improvement initiatives as managed generated waste that gets in the way of productivity. At Microsoft, we've adopted the teachings of Edwards Deming and stretched our MSF for Agile Software Development method to fit the requirements for CMMI Level 3. It's a highly iterative, adaptive planning method, light on documentation, heavily automated through tooling with management and organization enabled through agile metrics such as velocity and cumulative flow but with an added dimension of an understanding of variation - adapted from Deming's teachings. This is the story of how mixing Deming with Agile produced a lightweight CMMI solution for .Net developers everywhere.

Costs of Compliance:
Agile in an Inelastic Organization
   
Wednesday July 27, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
John J. Cunningham, IBM      
Abstract: Doing agile development in an inelastic environment, where policies and procedures are virtually unchangeable, creates an impedance mismatch between the agile team and its host organization. Our experience on a variety of embedded Java projects has shed some light on the costs of complying (or failing to comply) with the policies of the host organization. In keeping with the Agile philosophy, when our efforts were failing, we refactored our approach. We have trialed everything from "refusal to comply" to "full compliance". Regardless of approach, there was always an associated cost, such as redrafting documents, reducing functionality, spending time in meetings, losing focus on deliverables, or deteriorating morale. In the end, we were faced with the questions, "How did we fare? Which costs were worth bearing? Was it all worth it?"

Experience Reports
Thursday AM July 28, 2005
Agile Phase I
The Pragmatic Case Study of Schneider National.
   
Thursday July 28, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
John Mc Cormick      
Abstract: Schneider National began the journey toward Agile development last year. After doing some research the company sent three representatives to the 2004 conference in Calgary. Using some of the learnings gathered from the conference, Schneider began using Agile in a pilot mode. Schneider's approach was pragmatic in the sense that it took its current three release a year waterfall process and made changes in an incremental fashion. The steps included getting organizational buyoff for the pilot, forming the pilot team, breaking up a release into three 6-week iterations, constructing an open pod area for the group, integrating a offshore (on-site and remote site) element comprising 50% of the 25 person project team, and as of late introducing an offshore testing team strategy. Why is this a neat story? Because the first project incorporated delivering 17,000 hours+ in a 4.5 month time frame ... ahead of schedule and under budget with a substantial offshore component!

Agile Offshore Techniques - A Case Study    
Thursday July 28, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
Ajay Danait, Valtech India Solution      
Abstract: The case study will give a brief insight into the different techniques used by an Agile project team which was located at two different geographical locations. It will demonstrate how the teams used effective tools and techniques for collaborating. The case study also talks in detail about team dynamics and how the team gelled together as a unit in spite of being physically distant. It demonstrates how a flat organization structure can be effective rather than a hierarchical structure in using roles rather than designations. The case study also shows how the team switched from the development to maintenance mode with a different set of techniques which mapped sto those used in the development mode.

Follow the Sun: Distributed XP Development    
Thursday July 28, 2005 Morning
Full Text PDF File
PowerPoint Presentation
 
Monica Yap, Wireless Data Services Global      
Abstract: In early 2004, a global company with three independent development regions, United States (Seattle), United Kingdom (Poole), and Singapore, formed into one 24x5 round-the-clock XP team. A year after merging into one team, the company is effectively using full Extreme Programming practices across the world on a single code base. This experience report describes the challenges we face in this environment, lessons learned, and how we resolved issues such as global continuous integration, cultural differences, and conflicting priorities across regions.

Case Study of Customer Input
for a Successful Product
   
Thursday July 28, 2005 Morning
Full Text PDF File  
Lynn Miller, Alias      
Abstract: Both agile development and User Centered Design stress collaboration between customers and product teams, but getting these methodologies to work well together is not easy. This presentation describes one company's efforts to merge these processes by creating interconnected parallel design and development tracks. The benefits of this approach are demonstrated by showing how, when and why customer input was incorporated during the release of a successful software product.

Alias is the world's leading provider of 3D software for design, presentation will focus on a new product, Alias SketchBook Pro, which was developed using agile methods including frequent and timely customer input.

Experiences Integrating Sophisticated User Experience Design Practices into Agile Processes    
Thursday July 28, 2005 Morning
Full Text PDF File  
Paul Hodgetts, Agile Logic      
Abstract: Most significant software processes involve a wide range of disciplines, from programming to testing, and from documentation to database development. Unfortunately, agile processes are typically presented from the point of view of programmers, with the other disciplines often left feeling excluded and disenfranchised.
One such discipline is that of user experience design (often abbreviated UED or Ux), a discipline encompassing several key specialties including user research, interface design, visual design and usability testing. UED activities span the full lifecycle of product development from early requirements analysis to construction and testing, spanning both large scale system issues and detailed components, with its work products forming key inputs and deliverables of many development activities.
In this experience report, I discuss my coaching experiences integrating sophisticated UED practices into the agile process initiatives of several organizations. My background is initially that of a programmer and later that of an agile process coach, and I'll explore my journey understanding UED practices and how they map to popular agile processes, mainly Scrum and Extreme Programming. I'll chronicle the teams' struggles to come to grips with the often programming-centric orientation of agile processes, and their ongoing efforts to integrate their UED best practices into the incremental, collaborative world of agile processes.

Improving Communication between customers and developers    
Thursday July 28, 2005 Morning
Full Text PDF File  
Andrew Takats, Sapient Corp.
Nathan Brewer, Sapient Corp.
     
Abstract: Reducing waste and building a system based on the right requirements are key benefits of agile methods. Agile delivers on this promise thanks to constant business user involvement with developers, and frequent checkpoints of working software to encourage a tight feedback loop.
In multiple years of exposure to complex business problems that our clients present us, however, we have found situations where these traditional agile approaches have left us unprepared. In many cases, our clients simply cannot continuously work with us because of the nature of their business. In others, the complexity of the business problem is such that producing working code takes significantly longer than we would like. In both cases, we still need to make sure business people communicate well with developers, so that we can build the best system possible for our clients. In the context of an actual case study involving a system developed for the U.S. military, we present a suite of techniques we have developed to address these tough but not uncommon situations.

Experience Reports
Thursday PM July 28, 2005
The Cost/Benefit Paradox of Automated Acceptance Testing    
Thursday July 28, 2005 Afternoon
Full Text PDF File  
Prashant Gandhi, ThoughtWorks
Nils Haugen, ThoughtWorks
Mike Hill, Mandu
Richard Watt, ThoughtWorks
     
Abstract: Using FIT for automated acceptance testing supports a process in which developers and customers collaborate on a single executable specification for each story, i.e. the FIT documents.
By collaborating closely on the FIT documents, the developers and customers reach a shared understanding of the domain and develop the ubiquitous language of the application.
Our experience with this process was ultimately successful but not completely pain free. In this experience report we highlight the benefits and pitfalls and share techniques for achieving successful developer and customer collaboration in specifying executable FIT documents.

Test-Driven Porting    
Thursday July 28, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Ralph Bohnet, ClearStream Consulting
Gerard Meszaros, ClearStream Consulting
     
Abstract: Traditional Test-Driven Development focuses on development of new units (classes) driven by programmer-facing unit tests. This paper describes our experiences when using business-facing tests (also known as "story tests") to guide the porting of a legacy application. Domain experts specified tests in a tabular format using Excel spreadsheets. Developers automated these spreadsheets in various ways over time: scripts, generation of JUnit source code, and Fit. These tests were run against the legacy system and guided the development of the newly ported system. We found test-driven porting to be an effective way to port a complex application.

Ongoing Quality Improvement,
or: How We All Learned To Trust XP
   
Thursday July 28, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Mark Striebeck, VA Software      
Abstract: Since VA Software adopted XP 2 1/2 years ago, the understanding of quality and the product quality itself have changed dramatically. When we started with XP our code had alpha quality. Features were tolerably implemented, the UI was very bad and documentation was not even started. Today, the complete product (code, UI, documentation, SDKs) is constantly at pre-GA level. At any point in our development we can provide pre-releases to our customers without any additional testing or release effort. Before we adopted XP it took us up to 1 1/2 man years (6 QA engineers for 3 months) to bring a product release from development end to release. Our first XP release was 6 man months (4 QA engineers for 6 weeks). Now we are down to 6 man weeks (2 QA engineers for 3 weeks).

For experienced XP practitioners it might seem strange that the quality did not immediately jump to the high level that we have today after adopting XP. This was caused by a scenario that seems to be very typical for companies that have an established waterfall-based development process: the engineering team was enthusiastic about the new way of development, the product management team was indifferent and. the QA team was highly skeptical of the promise of XP to generate an (almost) bug-free product without a long and manual testing effort after development was done. Nobody in the engineering or product management team had any experience with XP, so it was impossible to convince the QA team otherwise. (In fact, reports of bug-free code from other XP teams were more intimidating then inspiring) So, we started our XP process without full QA involvement and a full system test phase after development was done.

This session recounts the evolution of our development process. It shows all the phases that our process went through, major changes that we made and what the overall impact was.

There Has to Be a Better Way!    
Thursday July 28, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Jon Spence, Medtronic, Inc      
Abstract: This is a story about how we influenced an organization developing Class III medical device systems and software to adopt Agile Software Development practices. Our story describes our frustrations with waterfall and plan-based methods, how we came to be interested in Agile and why, and how we facilitated the necessary changes. Finally, our story talks about surveys of our development teams that exhibit powerful evidence that we may actually be on the path to a "better way".

Waltzing with Changes    
Thursday July 28, 2005 Afternoon
Full Text PDF File
PowerPoint Presentation
 
Amy Law, TransCanada
Shawn Learn, TransCanada
     
Abstract: "The only thing that is a constant is change." - Greek philosopher, Heraclitus
This idiom is especially true when dealing with a software development project. With varying degrees, change impacts project delivery, budget, and quality. Often in today's environment, the requirements for higher quality software combined with compressed timelines and fewer developers can make change management a difficult task. This paper focuses on how agile practices play a role in managing changes in an industrial software project developed at TransCanada. We discuss how the impacts of changes in resources, changes in requirements, and external factors can be minimized. We examine numerous methods of overcoming challenges that often occur during industrial software development.

IMPORTANT DATES
Agile 2006 is being scheduled for July 23-28, 2006, at the Hyatt downtown Minneapolis.
Mark your calendars!
The Conference Wiki is up and running!