Mark Gilbert's Blog

Science and technology, served light and fluffy.

The Agile Path: Agile as a Journey (Part 1 of 2)

This is the first of what I hope will be several issues of “The Agile Path”, a semi-regular update on the “agile” state at BlueGranite – what we’ve done, lessons we’ve learned, and where we’re going.

Starting in late 2002 I started coming across material discussing Extreme Programming.  The more I got into it, the more I was intrigued by the approach described, and the activities prescribed.  I also started reading about some of the other methodologies that fall under the “agile” umbrella, such as SCRUM and Crystal and became convinced that, as a company, we needed to move in this direction.

The Big Break

For several reasons (which I will describe in Part 2 of this installment of “The Agile Path”), it took me until 2005 to find what I believed was the perfect opportunity to officially start down this path.  I had been assigned as one of two developers on a greenfield development project.  The client had done some organizing internally before we started working with them, and as a result had broken the project up into three major phases.  In April of 2005, we started Phase 1.

Phase 1 started out much like the other new projects – we spend a fair amount of time up front gathering requirements before we get into development.  I decided to introduce a change once we made it into development, however.  Instead of writing code for 2-3 weeks, and then turning everything over to QA in one gulp, we would post nightly builds of the application for QA to review.  This had several advantages:

  1. The development team got REALLY good at posting builds. One of the overriding requirements for the application that were writing was that the client’s IT department would eventually need to take over management of the application. As a result, by posting so many builds over the course of several months, we were able to smooth out most of the bumps, either in code or through good documentation.
  2. The QA resource we were using had other responsibilities during the normal business day, and worked on our application during the evening hours – after the development team had finished for the day. As a result, handing the application to him in small chunks allowed him to keep up, and not get inundated with 3 weeks of new development all at once.
  3. The nightly builds relieved a lot of the pressure in getting stuff done. While we still had milestone deadlines to meet, the pressure to get the project “done” by a certain date so QA could start reviewing it just wasn’t there. QA was reviewing what we did right along.
  4. QA was able to identify several issues very early in a given milestone, and we were therefore able to fix them early, before they caused additional problems for us later. If we had waited to release the project to QA until the end of the milestone, not only would we have caught those issues that much later, but more work would have been built on top of those issues.

This approach had a distinct disadvantage, though.  While we got really good at posting builds, we were still doing it manually – manually updating the test database, manually copying new build files up to the test server, etc..  We started using NAnt part way through the project to automate a lot of the process, but it couldn’t cover the database updates that we were making.  The nightly builds ended up adding a lot of time to what would turn out to be a 5-month project.

The Better Break

Despite these advantages, tubs of elbow grease, and buckets of aspirin, Phase 1 didn’t end well.  We were two months late in delivering the functionality, and the client wasn’t happy for a few different reasons.  During the project review we discussed the effect that the nightly QA builds had on the project.  In the end, the team agreed that the nightly builds didn’t contribute to the other issues that we hit during development, and in fact, probably helped alleviate some of their effects (some of these issues are described below).  We decided to keep this practice going into Phase 2.

To address the other issues that came up, we introduced a more agile approach to gathering requirements and building functionality.  We started with the list of high-level requirements for new features that were to be included in Phase 2.  We came up with an initial estimate for each, and organized them by priority into iterations.  So far, it’s not sounding too terribly different from Phase 1.  There were two key differences, though:

  1. We set the expectation with the client that the plan we put in place at the beginning was going to change. Changes in priority, new information about requirements, etc. would all conspire against our grand plan. As a result, we all needed to go into this project with the understanding that this was the initial plan, not the plan.  This modification was made to address the criticisms that we got during Phase 1 that we could never fully complete the functionality we laid out for a given milestone on time. We were always delivering the functionality later than the date we had planned on (in some cases) months before. This modification set the stage for everyone (developers and client ) to be more flexible about what progress really meant. During phase 1 “progress” was changed from “meeting deadlines” to “delivers new high quality functionality consistently”.
  2. At the very beginning of each iteration, we spent the day discussing the detailed requirements for the functionality that we would build in just that one iteration. We would then build and test that functionality during the bulk of the iteration. We would then deploy that functionality at the very end of the iteration.  This modification was made to address the criticism that we discussed functionality X in April, but it wasn’t until September that anyone got to see it in action. 5 months from discussion to deployment was now reduced to 2 weeks.

The results were astounding.  The morale of everyone involved in Phase 2 was 180 degrees from it was in Phase 1.  In fact, the client has sworn that they will never do another development project any other way.

In the second of this 2-part installment of “The Agile Path”, I will describe what we are planning on trying next, and I’ll take a step back and look at why we’re approaching agile the way we are – jumping in via tiptoe.


January 9, 2007 - Posted by | Agile

Sorry, the comment form is closed at this time.

%d bloggers like this: