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 11281 times

Related items

  • Filling Execution Gaps: How Executives and Project Managers Turn Corporate Strategy into Successful Projects
    What Filling Execution Gaps Covers

    Filling Execution Gaps

    by Todd C. Williams
    ISBN: 978-1-5015-0640-6
    De G Press (DeGruyter), September 2017

    Project alignment, executive sponsorship, change management, governance, leadership, and common understanding. These six business issues are topics of daily discussions between executives, middle management, and project managers; they are the pivotal problems plaguing transformational leadership. Any one of these six, when improperly addressed, will hex a project's chances for success. And, they do—daily—destroying the ability companies to turn vision into value.

    Check it out on Amazon or the Filling Execution Gaps website

    Without the foundation of a common understanding of goals and core concepts, such as value being critical to success, communication stops and projects fail.

    Without change management, users fail to adopt project deliverables, value is lost, and projects fail.

    Without maintaining alignment between corporate goals and projects, projects miss their value targets and projects fail.

    Without an engaged executive sponsor, scope increases, goals drift, chaos reigns, value is lost, and projects fail.

    Without enough governance, critical connections are not made, steps are ignored, value is overlooked, and projects fail.

    Too much governance slows progress, companies cannot respond to business pressures, value drowns in bureaucracy, and projects fail.

    Without strong leadership defining the vision and value, goals are not set, essential relationships do not form, teams do not develop, essential decisions are not made, and projects fail.

  • 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 hesitate to 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 symptoms 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.

Leave a comment

Filling Execution Gaps

Available Worldwide

Filling Exectution Gaps cover

Filling Execution Gaps is available worldwide. Below are some options.


PG DirectLogo
Limited Time Price $20.99
Amazon logo
Book or Kindle
Flag of the United States Canadian Flag Flag of the United Kingdom Irish Flag Deutsche Flagge
Drapeau Français Bandiera Italiana PRC flag
Japanese flag
Bandera de España
Flag of India
Bandera de México
Bandeira do Brasil
Flag of Australia
Vlag van Nederland
DeG Press Logo
Barnes and Noble Logo
Books a Million Logo
Booktopia Logo
Worldwide: Many other
book sellers worldwide.

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

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.