Agile development methodologies aren't one-size-fits-all. Independent software vendors (ISVs) have unique needs-external customers, aggressive release dates and competitive pressures-that require tailoring software development methodologies that work well in corporate IT settings. Faced with a major new project and bogged down by a big design up-front process, VA Software adapted Extreme Programming (XP) to help build the latest versions of SourceForge® Enterprise Edition (SFEE).
Extreme Programming Within The ISV
VA Software has been at the center of the open source revolution since its inception. Launched in 1999, SourceForge.net® quickly became the global nexus for the open source community. Today, it's the world's largest open source software development web site, hosting more than 106,000 projects and over 1.2 million registered users-over 80 percent of all open source projects worldwide. VA Software also runs Slashdot®, freshmeat, Linux.com and other Websites serving the IT community.
Leveraging SourceForge.net's success and
Advertisement
scalability, VA Software developed SFEE. SFEE is a secure platform for optimizing development within distributed organizations, connecting heterogeneous processes together with a suite of project, change management and collaboration tools. Many Fortune 1000 companies and government agencies use SFEE to integrate disparate teams, expand visibility and improve collaboration.
Making the Leap
In early 2002, VA Software decided to completely rewrite SFEE, its flagship product. As demand for the enterprise version of SourceForge grew, it became clear that architecting such an application was going to be a different sort of project. The rewritten application had to:
Run on multiple operating systems,
Work with multiple databases,
Integrate with multiple software configuration management systems,
Provide a broad and capable API for integration with external applications and for ease of implementing SFEE extensions,
Offer extensive role-based access control, and
Boast a state-of-the-art user interface.
At the beginning of the project, the 3.x version of SFEE comprised approximately 500,000 lines of code-the fruit of over 50 engineering years of development. The team estimated that it would take 18 months to build a new version. Further, the platform needed to change from PHP scripting to a three-tier J2EE architecture. This was no small endeavor. A major change in methodology, therefore, was unlikely at such a juncture.
The rewrite team responsibly began using a classic "waterfall" approach to the project: defining sequential phases for determining scope, designing the application, writing the source code, testing via an independent quality assurance team and, finally, deploying the finished product. As the prescribed number of months passed, the team (15 engineers, four QA engineers, three product managers, one UI designer and one technical writer) made progress on the new framework. The framework supports such applications as the bug tracker, task manager, document manager and discussion forums with role-based access control, monitoring and indexing, among other functionality.
After six months of framework development, however, the waterfall approach began holding them back. The plan stated that it was time for the product managers to deliver functional requirements documents to the engineers. But given the vast scope of the applications, the product managers needed more time to consider which features to add, modify, continue or discontinue. The engineering team was at an impasse: Was there another way to keep the project moving? The answer, the team hoped, would be an iterative development process that would allow design and implementation to occur in tandem. They selected the Extreme Programming (XP) methodology because it allows continuous requirements discovery and evolution, resulting in accelerated development and greater responsiveness to customer needs.
Only the product engineering director had had practical experience with an agile methodology. Introducing XP required a cultural shift within the organization-and agility training would have to occur while still meeting current production schedules. The team was presented with the initiative and asked to study two books, Extreme Programming Explained [[i]] and Planning Extreme Programming [[ii]]. For several weeks, the team leaders immersed themselves in these tomes, evangelizing XP guru Kent Beck's revolutionary approach to tackling the twin burdens of software complexity and project predictability.
Due to its track record of successful releases prior to this project, the team had banked sufficient organizational trust to be given carte blanche in its new embrace of XP. The vice president of product development did what any good software team leader would, exercising his influence to convince other departments that the new version would be delivered on time-XP or not.
Before and After
During application development, the team used XP with two-week-long iterations (see Figure 1). The product managers found this process enabled them not only to define functionality in small chunks, but also to refine features. To the product managers' delight, a working version of the application was always available.. Furthermore, the UI designer discovered that, whereas he would normally be pleased with 70 percent progress on the interface, XP enabled near-100 percent completion of the UI in tandem with the application rather than as an afterthought. However, a big question remained: How would the quality of the code compare to previous releases?
The QA team began testing in December 2003 on JBoss and in January 2004 on WebLogic. The results were impressive: No integration phase was needed (past releases had occasionally necessitated a week spent creating a first installable version) and the bug rate had dropped significantly (see Figure 2).
Having received a clean bill of health, two new versions were released in late 2003/early 2004, followed by three more major versions and six service packs. The entire organization so impressed with the speed with which the team launched new versions and the newfound flexibility of the requirements discovery, that it has adopted XP as its standard process for all development activities.
Involving the QA Team
As its adherents know, XP's focus on test-first development has caused software engineers to view testing as a necessary precursor to programming. Less clear in the XP methodology is the role of a traditional quality assurance (QA) team within an ISV-an understandable gap, given XP's origins within a corporate IT shop rather than a software house.
In SourceForge's case, QA did not participate in the early stages of the SFEE development process. Rather, after the code freeze date, QA prepared and executed written test scripts. Having found no integration issues and a very low bug rate in the first release, QA hankered to participate in the early-stage development of the next release. The group abandoned written test scripts but kept its own automated test suite. Through constant testing of new user stories, the QA team could extend its own suite gradually. By the time all user stories were implemented, QA had a fully updated test suite for final system verification. VA Software is exploring how to make the test suite more accessible to non-engineers and QA by using a tool such as Ward Cunningham's Framework for Integrated Test (Fit).
Becoming Test-Driven
After practicing XP for two and a half years, there has been a sea change in the development team's outlook. Quality is no longer an amorphous afterthought. Today, the development team-a truly representative group of stakeholders-strives to keep quality constantly at a pre-GA level by iteratively creating final production code and documentation, and continuously checking for cross-platform correctness.
Figure 2: Post-Development QA time and Bug rates of SFEE releases before and after the introduction of XP.
Using XP has significantly compressed the time spent testing a release after development is finished. The lower bug rate, in turn, has resulted in a cost savings by reducing the size of the QA team by two offshore QA resources.
Another indicator of the significant process improvement SourceForge has enjoyed is the pre- and post-release day activities. Prior to adopting XP, several sleepless nights generally ensued before the release in order to fix any remaining bugs, conduct final QA verifications, collect missing pieces such as documentation and package the release files. Today, release files are generated throughout the development lifecycle. The release activity consists only of creating a tag for the final code-and serving champagne.
The SourceForge experience with XP mirrors that of many successful ISVs: Evangelization by developers on a single project soon encompasses the entire organization. Further, the improvements in quality and predictability stimulate new investment in software development activities. Agile methodologies are a perfect fit, in VA Software's experience, for a software house that caters to large IT customers and the open source world.
About the Author Chary Aasuri, Sr. Software Architect for VA Software, leads the design and development of SourceForge Enterprise Edition. Chary joined VA from Pensare Inc., an e-Learning company where he was responsible for architecting Pensare's Knowledge Community platform. During his twenty-year career, Chary has served as a software architect at Intergraph Corporation (India). At Adobe Systems Inc. Chary managed FrameMaker+SGML/Viewer products and delivered several versions of the products. Chary was responsible for architecting FrameMaker+SGML publishing product at Frame Technology (acquired by Adobe Systems). Chary received a bachelor's degree in Electronics and Communications Engineering from Osmania University in Hyderabad, India and a master's degree in Computer Science from the Indian Institute of Science in Bangalore, India.
Blogs 
