My Agile Adoption Story

My first experience with an Agile project that was more Agile than Waterfall was in 2006. I phrase it in that way as all projects I have been on have had some aspects of Agile. But I digress, back to the story…

In December of 2005 a fixed price RFP was released for a new Parks Reservation Service that the Government of Manitoba required completion for the spring of 2006. (April 3rd to be exact) We were very diligent in planning to even respond to the RFP as we knew what a challenge the requested time frames would provide. So we met with the proposed team and held a risk session/planning session/estimating session to determine if we felt this was do-able and if we all were comfortable with bidding. It turned out that we thought this was certainly do-able, but it would be a challenge right from the start. We took a vote in that session and it was unanimous that we should bid. We thought that we needed to execute the project in a way that was more Agile than we ever had done before to be successful. This meant to us at the time:

• Team Chemistry and continuity
• At least 1 client on site full time with full decision making authority
• Daily stand-ups
• Fully empowered team (This is normally the way we operate)
• Very lean Use Case requirement documents.
• Demos at least every week to show progress
• Team Planning and Estimating
• Visual Project Management

What were we missing?

You may have noticed several current key Agile practices that were not in our list. Such as:

• Test Automation
• Continuous Integration
• Kan Ban
• User Stories
• Planning Poker
• Pair Programming

But before we get to that. Let’s provide some context for the project.

The Problem

• Dimensions of Parks and Campgrounds
• 57 Campgrounds
• About 5,500 campsites
• 11 Campgrounds currently computerized
• Requirement was for a Web Application that need to be used by three types of clients:
• General Public to make reservations over the internet
• Call Centre employees to make reservations on behalf of campers.
• Campground attendants to manage inventory, make reservations on behalf of campers, and check-in/check-out campers
• Web Application needed to have the following main components:
• Welcome/Login
• Shopping Cart
• Campground Management
• Inventory Management
• Reservation Search
• My Account
• Reports
• Reservation Maintenance
• Reports
• Policy Configuration
• Integration with online payment provider

Kick off to Deployment in 92 days

To meet the required deadline, we made the following project execution decisions:

• We partnered with three other companies to provide expertise so we could hit the ground running. (We could have learned this expertise but we did not have the luxury of time to do so)
• We did not have experience in test automation and felt it would be too risky to learn on this project. To mitigate this we allocated an Application Architect to manually perform Quality Assurance activities daily.
• We allocated an additional Technical Architect to Performance Test the application for the first three months.
• We leveraged Protegra Frameworks to speed up development velocity.
• We had a Technical Spike to validate and confirm what GIS mapping solution we would use.
• We separated the project into three phases to be able to deliver the functionality when it was required:
• Phase 1 – Public and Call Centre Focus
• Functionality focused primarily on the reservation process and reservation maintenance (i.e. making reservations, changes, cancellation, payment, refund, etc.)
• Phase 2 – Campground focused
• Focused on management of campgrounds (i.e. check campers in, check campers out, move campers, camping permits, revenue reconciliation, etc.)
• Phase 3 – Admin site enhancements
• Focused primarily on providing more back office support to Parks head office users

The Solution

The Solution was a C#, .NET Solution. The database was SQL Server and the architecture was a standard three-tier architecture.

Project Details

• Project team included over 20 developers at maximum
• First Phase was delivered in 3 months.
• Included investigation and integration of GIS mapping technology
• Phase 1 alone was over 7,400 hours of development work, all three Phases were over 12,000 hours.
• Quality of the application has exceeded industry standards with only a few defects since go live

The Outcome

The solution was deployed to production on time on April 10th, 2006. For those of you keeping track, this was a week later than initially planned due the time required to train the users. The solution was ready to deploy on April 3rd. This was after the project learned a month before go-live that the code had to be frozen two weeks prior to go live to allow for the acquisition of PCI certification to take on-line payments.

The project was awarded the PMI project of the year (Manitoba Chapter) for 2006.

What We Learned

• Client decision maker on site is key to a Lean project.
• Liaise with the clients as much as possible
• Empowering the development team was crucial.
• Traceability of requirements is key with formal organizations
• The team succeeded because they trusted one another

What we would do differently

• Quality could be further improved with the use of TDD, automated test and build tools
• Form in sub-teams of 6-8 to maximize efficiency. Assign a Client decision maker to each one of these sub teams.
• Leverage Visual Project Management to an even greater extent
• Develop in Iterations, not increments. We really developed fully functioning increments.
• Use the following Agile practices:

• Test Automation – We mitigated this risk by assigning one of our top Application Architects, but I would not recommend this approach unless you have no alternative.
• Continuous Integration – We probably got away with this because we coded in increments. If you are doing iterative development, I believe you need Continuous Integration.
• Kan Ban – We did not use a traditional Kan Ban board. We now use these on all projects.
• User Stories – Use Cases were still too large and they were really why we developed in increments. I don’t think you can deliver in Iterations without User Stories.
• Planning Poker – We had a very senior team who felt very comfortable in a joint planning session and challenging each other’s estimates. I wouldn’t recommend this going forward though as this team was very unique.
• Pair Programming – Strangely enough, this is one Agile practice that we rarely do. We typically use it more for a mentoring opportunity. The book is still out on this one though as I would like to try it on a project.

Why we succeeded

In some ways we succeeded primarily because of the excellent people and team we had. I believe that is still a key factor in the success of projects. That said, Agile practices do result in better solutions and everyone on the team realizes that we could have had an even better solution and project with them. (And certainly a more stable pace)

I believe we also succeeded because we had the client decision maker on site. This was not just any decision maker though. The Client was a person that had lived and breathed working with the old system, creating the RFP, and knowing what she wanted from a new system. In short, our client on site was also our Product Owner. Very powerful…

Check it out

If you want to check out the solution, you can find it at the following link:

http://prsasr.gov.mb.ca/