The StoneHenge blog

Just like the software development industry as a whole, we too have experienced problems before integrating Agile Development into our methodology.

Every year the Standish Group publishes the Chaos Report. Every year the story is virtually the same: large software development projects are 220% past due, 190% over budget, and deliver only 60% of the originally specified functionality.

In 2007, StoneHenge Partners experienced one such project. It was originally estimated to be a 6-month waterfall-managed project for 6 developers. Then, during development, the project's scope grew by 260%. We billed a 50% increase in price, doubled the size of our team and delivered the project in 9 months. However, the project wasn't very profitable for us and the client ultimately chose not to implement because the data model they had given us was inaccurate.

The primary lessons we learned from this experience? We need to:

• Use an accurate method to size projects and manage scope creep.
• Develop and test code in iterations.
• Establish project metrics based on code delivery, not just percent of hours worked.
• Rely more on frequent business user input, data models & user interface diagrams than on text-based requirements created at the start of the project.

From this experience we knew we need to change our development model if we were going to be competitive.

Lessons learned

"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."
--Charles Darwin

Mike Fletcher, StoneHenge President, gave us a directive to incorporate the changes. As a result, the Nimble℠ Method was born.

We embraced 10 of the 12 Agile development tenants, while retaining the upfront requirements gathering portion of the Waterfall method and then adding the use of function point analysis (FPA) to accurately size projects and efficiently manage change throughout the SDLC.

We also found a collaborative modeling tool, Enterprise Architect, which allows us to minimize the effort required to document system requirements and designs. Another way we reduce the effort required, is through developing, testing and delivering code in 2 to 4 week iterations. As a result we are able to discover defects early and learn how to prevent them in the following iterations.

How big of an impact does this have? Well, according to Capers Jones, (Applied Software Measurement), "Over a typical software life cycle, more than 50% of the total accrued costs will be associated with finding and repairing defects." This is huge! For example, if we had used this approach on the project above, we would have discovered the Client's Data Model error very early on.

So what has been the result of using Agile development methods in our new Nimble℠ Methodology? We have successfully implemented eight projects in a row and are working on our ninth. Below is a summary of our project metrics from our first 3 software development projects after adopting Agile development:

Average ratio of Actual Hrs. vs. Planned Hrs. = 110%

Average ratio of Code Delivery Date vs. Plan = +2.67 days

In summary, we are now able to consistently deliver projects on time and on budget and with very few defects, while significantly reducing risk for both StoneHenge and our clients. Remember the software development industry problem mentioned above about projects being late and expensive? Well, we believe incorporating Agile development into our service delivery method has allowed us to solve that problem forever.