Case Study: Using Agile in a Project Recovery

Getting Buy-in to a New Process

Getting people to change to an alternate method when they are familiar with it is difficult. Getting people to change to something they are unfamiliar with is even harder. Therefore, changing to an agile methodology, which is very different from other project methodologies, can be a significant challenge. To be successful you need an opportunity to demonstrate its power without making executives commit to something that might be perceived as too risky. Agile builds in a phase to help with this. Each iteration ends with an adapt phase allowing the methodology to change to meet the specific application. Proposing and executing an iterative approach in the implementation quickly shows the benefits and minimizes risk.

Agile in a Recovery

Last week the discussion was that maintenance should be removed from all projects. At the end of that article, there were three possible solutions. Following is a case study of a hybrid implementation of two of those options—creating a small bug fix project and reestablishing the maintenance group. To implement this in rapid short cycles, an agile methodology was used.

The example comes from a client developing an application internally that would be used throughout North America at hundreds of franchised and internal organizations. The product had major features developed and deployed in sequential nine- to twelve-month cycles using the classic waterfall approach. They had dissolved the maintenance group in favor of a fully matrixed organization. Product maintenance—bug fixes and minor enhancements—comprised about one-third of each project's scope.

Franchised dealers, sales, and order processing organizations were not pleased with the lengthy turnaround time for minor enhancements and bug fixes. However, executive management was unwilling to try new approached since the product had been plagued by multiple maintenance and management problems (mostly from long lead-time monolithic releases).

Logistically, all the tools were in place for frequent releases—the internet-based distribution infrastructure was already used for project releases. It was quite reasonable to use an iterative approach.

I approached the key stakeholders and discussed the concept of creating periodic service packs (using examples of other commercially available packages). They liked the idea, but felt the organization was too immature to handle the process. After significant lobbying, they acquiesced and agreed to running a test.

Certain that the approach would work, I developed a longer term plan and shared that with the project's core team. The approach proposed was:

• Demonstrate the ability to release bug fixes separately from the project cycle.
• Work with the customers to prioritize the feature list and initially restricting the changes to the simplest of enhancements and critical bug fixes.
• Segment the project to create a small sub-team to implement and test the maintenance features using an agile approach.
• Show success in deploying minor feature enhancements.
• Improve the process to include larger enhancements.

Planning How the Work Should be Done

The product manager, development lead, and I (the core team) analyzed over 1,500 defects and enhancement requests in the bug tracking system. In a two-day prioritization session, each item was assigned a value for its relative effort to complete (small, medium, large, and too big for an iteration).

The next task was to study the electronic distribution system. If product releases were to happen on a monthly basis, this system had to run flawlessly. Reports on deployment penetration would be needed to show the processes value. Unfortunately, the subject matter expert had left the company leaving little documentation. A junior resource inherited the system but all training requests were suspended due to cost overruns on the project. A developer was assigned to work with the junior resource to expedite his understanding of the product. Through this process, the system was tuned, the junior employee was mentored, and the reports were generated.

The core team recruited two volunteer developers and a skeptical quality assurance lead. I wanted a release every four weeks. This implied an average of two weeks for development and two weeks for regression. Development and regression testing could overlap by a week. This timeline meant that approximately 160 hours could be spent on an iteration by each group—two people for each group for two weeks.

Executing the Plan

Since this process was new to the team, it was introduced slowly. The first service pack included only bug fixes, changes to features were strongly discouraged.

Many aspects of how the team did work needed to change. For instance, instead of the traditional functional specification, the team agreed on a new single-page feature definition document. This included screen mockups, behavior and validation rules. It was designed so QA could use the same document for testing.

Daily status was gleaned from each team member individually. Weekly status reports and two weekly meetings were abolished. Any questions or concerns were given the highest priority and addressed promptly. Developers, QA and the customer worked in tandem to make all changes. After a feature was complete, QA would regression test the features while the developers and the customer would start investigating the next iteration's work.

The first release resulted in fixing thirty-five major and over one-hundred minor (cosmetic) and medium (non-functional, cumbersome) bugs. The response from customer and steering committee was phenomenal. Penetration of the release to the sales force was approximately 80% in the first twenty-four hours and within a couple of hours positive effects were evident in the order processing organization.

Team confidence skyrocketed. Both the customer's attitude toward the team and the team's self-confidence made a quantum leap.

For each iteration, the development cycle was altered. These changes included:

• Allowing reprioritization and new requests. Trade-offs were usually required and, with facilitation, the customer adapted and followed the process
• Increasing the number of items to fix or add
• Streamlining communication between the development team and the requester by removing the business analyst

Conclusion

The implementation was not without problems; however the process was so successful that the team was eventually removed from the project and kept as a core group dedicated to the product.

A couple of years later I was in a meeting and mentioned that the agile methodology was used at that company to recover a project. Many people argued that the company had never used the agile. After a fifteen minutes description of the application all agreed it had enough of the characteristics to qualify. It underscored the value of agile as a tool.