Tuesday, July 13, 2010

Changing "How" GiftRAP Develops Software

I came to GiftRAP in June 1998, right as PPS and mandatory submission of the MDS were making their debut. At the time, there were only three of us at GiftRAP, and we did everything including requirements gathering, development, testing, software deployments, tech support and sales. With all of these hats to wear, we had to be efficient and agile.

Suddenly, in the mid 2000s, we rapidly added customers, revenue and employees. Slowly but surely, our agile beginnings were replaced by rigid processes and lots of documentation that nobody would ever want to read.

Then, one day last year, we took stock of where we were, and we realized we had become bogged down in "big up-front design". We were spending so much time "designing" that we didn't have time to actually implement. When implementation was complete, it wasn't uncommon to find that either the end-user expectations had changed or our product managers missed the mark.

We were "eventually" delivering valuable functionality to our end-users, but it was just taking way too long. Something had to change!

We had to get closer to the way we did things in the "old days" when Steve Mackie and I sat down next to our one and only developer and collaborated on the best approach to address our customer needs.

We started exploring new ways of developing software that would return us to our agile roots that enabled us to create great software that would "wow" our customers and prospects.

It didn't take long before we recognized the development methodology called "Scrum" as the perfect fit. Incidentally, Scrum has become the most popular agile development methodology in recent years, so it is well established and respected in the software development community.

In January, we made the jump from a typical "Waterfall" methodology to "Scrum" which prescribes great planning, "just in time" design decisions and heavy collaboration between developers, product owners and end-users (customers).

Rather than long release cycles of 3 to 6 months associated with Waterfall, Scrum prescribes development iterations referred to as Sprints ranging in length from 1 to 4 weeks. We generally run 2-Week Sprints here at GiftRAP.

The cool thing about Scrum and the prescribed Sprints is that each successful 2-Week Sprint produces one or more pieces of "potentially" shippable functionality that are valuable to our end-users. Our Scrum Team Members, consisting of developers and testers, present a 30-Minute demonstration of the functionality they completed and tested at the conclusion of each Sprint. This gives our teams the reward of showing off what they did during the last two weeks, and it gives our Product Owners (customer representatives) the opportunity to inspect and "accept" the new functionality as "complete". To be accepted, the functionality must be fully implemented and tested by the Scrum Team. They are not even allowed to demonstrate functionality that has not met these criteria.

With 6 months of Scrum under our belt, I can say that the change has been a tremendous success for GiftRAP. The benefits have been abundant:

- Faster development of features
- Significantly higher quality
- Increased visibility for our senior management and customers
- Increased predictability as to when features will be "done"
- Better features being produced

While we have witnessed all of these benefits at GiftRAP, they haven't been visible to our customers "yet". This will change soon with the release of ROX 4.0 in September. Although we have produced valuable functionality in recent months, deployments have had to be withheld until MDS 3.0 changes are completed. Following the release of ROX 4.0, we have the opportunity to deliver valuable functionality in short periods of time that we know will "wow" our end-users. That's exciting!

No comments:

Post a Comment