Sunday, 09 May 2010 00:00

Case Study: Using Agile in a Project Recovery

Rate this item
(0 votes)

The Pointed-Haired Bosses Concept of Agile

Full implementation of agile project management requires a top-down approach. The differences in reporting, resource dedication, team structure, and customer relationship from traditional project management methodology requires buy-in at the highest level of the company. Educating superiors and customers on the benefits of agile project management is difficult, especially if they have a religious belief in classical project management style. Implementing a pilot project is the best way to quell their fears. Unfortunately, in a recovery this luxury is unavailable—the turn-around becomes the pilot.

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


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.

Read 5454 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)

    Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

    No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • Project Inception - Designing Organizations For Success

    Buy it now!

    A failing project’s fate is destined long before assigning a project manager. Its doom is sealed from the time the customer envisions the idea. Traditionally, project inception is defined as when the customer comes to a solution provider (internal or external to their organization) asking for a product or service. In actuality inception is much earlier. It starts when someone says, “Wouldn’t be neat if I could...” From that point forward the customer’s exceptions are set, changed, and reset as the process of discovery refines the concept. The customer’s ideas change from what they want to what they need, while continually constrained and formed by the realities of an ever-changing business environment. Although people cite unrealistic expectations as major problem during inception, the constant change in expectations causes the real issue—misalignment. For project managers to make a significant difference in a project’s success, they must use a new paradig.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References