Case Study in Agile Development at Accela, Inc.

This is my experience implementing agile development at a commercial software company while I was manager of engineering operations there between April and November 2007. Software development was performed by the company's offshore partner. Until April 2007, the development process used a waterfall approach wherein functional requirements were written in a Functional Requirements Document. Based on that document, the assigned developer would create a technical Design Document. After an engineering development manager in our office approved the Design Document, the developer began development. During the development phase, a tester would create test cases and at the completion of development that tester would perform the quality assurance tests on the software.

At one point during the spring and summer of 2007, the combined number of managers, developers, and testers dedicated to our products by our partner exceeded 115.

The rationale for moving to an agile methodology included:

• manage changing priorities – several products were not yet mature and yet were being installed at customer sites. This meant a steady stream of enhancement requests and bug reports that needed to be addressed in the earliest possible release cycle.
• Accelerate time to market – the company was producing a new citizen access product in response to demand from a dozen or more customers. The desired delivery timeframe was 6-8 months or roughly two quarterly release cycles.
• Increase productivity – the development team was experiencing downtime during the standard development cycle and we wanted to eliminate this waste.
• Increase quality – product releases typically were buggy and customers required lengthy testing periods prior to deployment in their hosted environment.
  

These are the actual practices we implemented as part of the agile methodology we adopted:

• Modeling/prototyping – we emphasized a graphical mockup/prototype over a verbal requirements document. This helped all stakeholders, who were geographically dispersed and seldom able to be in the same room at once, stay on the same page regarding product features.
• Iteration planning – we determined that 3-week iterations would be ideal and included as many iterations as the release schedule allowed (usually 3).
• Daily standup – we scheduled a recurring meeting at 9:00 a.m. each day to review project status and discuss issues, with the key questions:

What have you accomplished in the past 24 hours?

What do you plan to accomplish in the next 24?

What obstacles are preventing you from what you need to do?

• Release planning
• Continuous integration – automated builds were deployed to our integrated system test environment based on the latest code checked in by developers. We knew each day if something had been introduced in te code that broke the build.
• Refactoring – we tracked where “hacks” were used to complete a feature and in subsequent iterations/release cycles we refactored that code.
• Collective ownership – any developer was authorized and obligated to make corrections to any code that had been checked in for deployment in the daily build.
  

Tools we used include:

• Wiki
• Online forum
• Spreadsheet for issue tracking
• Bugzilla for bug tracking
• Testopia as a test case repository
• SubVersion as a code version management tool
• Ant for continuous integrated build management
  

Results included:

• 100% increase in productivity as measured by features and functionality added during release cycles using agile methodologies compared to releases using the waterfall methodology during the previous year.
• Significant reduction in bugs/code errors as determined by the number of issues reported by customers who installed and tested the software in their hosted environments.