My Blog

I enjoyed reading this piece very much. We ran into an issue with the project we did for Marriott, where we did fewer wireframes than we should have up front, and went into design mode too fast. Ultimately, we went back and did wireframes, which got us back on track.

We also made a clickable prototype. Basically, we took the images from the designs, and then ordered them in a certain way. Clicking anywhere on the image went to the next image in the sequence. This allowed us to go through a user story, and show the client how things would look and work. The client was also able to use the clickable prototype to show the early drafts to target audiences and gather feedback. It was helpful, and it helped build user enthusiasm for the project.

During a recent job interview, the topic of Agile vs. Waterfall was brought up. Specifically, I discussed a job I did for a government agency, where it was mandated that a waterfall approach should be used. I was asked a basic question, “Would agile have made more sense?” I don’t think there is a right or wrong answer here. In this case, of course, the methodology was mandated by the client, but let’s set that aside for the purpose of this discussion.

First, some background on the project. The agency had an old database running on a PowerPC Macintosh using a pre-OSX version. I think it was Macintosh OS 9.  The program was created in 1999, and 12 years later it was still chugging along. It had several major issues, though:

1. The version of 4th Dimension was old, running on old server hardware.
2. It was slow
3. It was hard to find programmers to fix issues or update the program
4. User access required the use of client software installed on PCs.

The agency had tried to launch a new program with new features, to replace the existing software. That project failed. When the company I worked for was brought in, the scope had been scaled back. Instead of adding new features, and migrating over the old data, the new scope called for 100% feature duplication of the old system, but built on a .NET/SQL framework. A possible “Phase 2” would build on that foundation and add new features.

One quirk of the existing system was that there were many areas where a report or input screen existed, but nobody currently at the agency knew why it was there, or what it was used for. The contract called for 100% duplication, though, so time was spent duplicating the reports and fields that were probably no longer used.

There are a couple reasons a waterfall approach made sense for this project.

• Defined scope: Project success was measured in how faithfully the new program reproduced the functionality of the old program. While some allowances were made since we transitioned to a web interface, we knew exactly which screens and reports were needed, and what fields showed up on each.
• Change approval: The process to gather approval for wireframes and designs was somewhat involved, and required sign-off by several people. As such, the designs, once approved, were unlikely to change. And approval for changes took a long time to work through the chain of command. From the start, it was agreed that changes would be kept to a bare minimum for the initial work.
• Training time: The program was used by many people in the agency. As such, group training was organized for several periods after the project was completed. Having the project 100% completed by a specific date allowed the users to be trained on the full system, with no changes happening afterwards.

Using Agile, however, there would have been a few benefits over the more traditional Waterfall method.

• Delivery time: As mentioned above, there were many reports and some input screens that were no longer used. Using agile methodology, those reports and screens could have been added to the product backlog, and been completed during a later iteration, after the product had launched. This might have required additional user training, but in our surveys we found literally zero users of the system ever used some of the reports.
• Earlier User Feedback: When the final product was launched, that was the first a lot of people ever saw it. While we tried to incorporate the heaviest users of the system into our testing and client feedback, we did not capture everyone’s views. Having feedback from the larger group earlier would have changed a couple design decisions, instead of having to retrofit them into proposed Phase 2 updates.

I think the main benefit of using Agile methodology would have been the ability to launch the site faster, with the core set of reports. Then adding on the less used (or never used) reports during a later sprint. Or being able to talk the client out of including those reports and using the development time for something more beneficial. That was probably not in the cards, but hope springs eternal!

I am 700 words into this post, and have not given my thought on the best way to go for this project. With hindsight being 20/20, I am comfortable saying the approach used was probably the best for the project. Besides the fact that it was mandated in the contract, the client had a level of comfort with Waterfall, and understood the steps involved from start to finish. Agile would have been outside their comfort zone, and that can sometimes cause issues later on, if you hit any bumps. And in this case, while a faster delivery of the core functionality would have been nice, it was not critical enough to try and change their mind or the contract.