Agile Case Study

REAL WORLD EXAMPLE

Agile processes represent an evolutionary step in the maturation of IT systems development. As a Senior Software Developer and Systems Developer for the past eight years, I adopted similar methods on my own for developing web-based IT systems by applying Quality Management (QM) process improvement techniques to IT system development. QM enabled me to optimize and streamline the development process by identifying areas where no value was added to the project by assigned resources and to eliminate waste by reducing some of the required documentation. Applying QM also resulted in high levels of customer involvement and feedback throughout system development, which helped ensure the project better met their needs and provided an effective method for managing expectations. However, the most significant concept I learned from agile development was to build systems in small modules through iterative cycles involving the customer. Instead, I was accustom to more traditional methods for building work lists and producing large upgrades/change modules in six month cycles. Although six months cycles worked, the amount of change was large, harder to manage, and customer expectations were more difficult to manager as well.

Since learning of agile development, I decided to test the process by building a new data collection system in 30 days. The system was intended to support an internal organizational resource study and involved two web input forms, a relatively small data base, and four fixed output reports; refer to functional diagram below. The development involves a concurrent process which significantly reduces the amount of time to deploy the system and collect data. The project timeline looks something like this:

FIRST WEEK: Develop input form and data base and obtain customer approval.
SECOND WEEK: Train down stream end-users how to input data.
THIRD WEEK: Down stream end-users input data, while the upstream end-users design outputs.
FOURTH WEEK: Develop output reports and obtain customer approval (3 cycles for 3 reports).

This development schedule produces an functioning system in 14 days, and a completely operational system by the 32nd day of development. A traditional approach would require completing 100% of system development (4 weeks), before training (1 week) end-users, and collecting data (1 week), which would require at least 6 weeks time. The agile process resulted in users entering data into the system 60% faster than traditional development processes (i.e. 2 wks vs. 5 wks), reduced in overall process of collecting data and producing reports by 33% (i.e. 4 wks vs 6 wks).

MARCH 2006 UPDATE:

SOME CLARITY:

There are three user groups associated with this project. To eliminate the need to provide another graphic, lets call them End-Users (EU), Middle-Managers (MM), and Senior-Managers (SM). There are 197 EUs, 12 MMs, and 5 SMs. In addition, there is there is Control Group (CG), comprised of a 10 person team that is managing the study supported by the data collection system. I function as the IT consultant and IT Project Manager, and there is one developer proficient with Dream Weaver and Database Software.

PROGRESS:

WEEK 1: During the first week I used stories for conveying to the developer what the CG was looking for, which he used to produce four different versions of a front end for collecting the data. Every time I showed them to the CG, they saw different aspects of the data collection process and requested changes. By the end of the first week, we had a front end the CG was satisfied with, and everyone agreed to move forward with a three day conference involving MMs, SMs, and a group representing 10% of the EUs.
WEEK 2: The first two days of the conference involved the MMs and SMs. The EUs were scheduled to be brought in on the third day.
The conference started with an overview of the project, goals, objectives, and timeline. Around 11:30 in the morning of the first day, I presented the concept of agile development to the entire group (see timeline above), and immediately after lunch demonstrated the front-end of the data collection tool as it existed at the end of week one. The presentation lasted approximately 30 minutes, after which all participants were divided into five subgroups that met to discuss a different aspect of the data collection process and evaluate the tool. After two hours of discussion and analysis, everyone was brought back together and described their aspect of the data collection to the group as well as recommended changes to the tool. Changes were discussed at length and consensus was achieved on each one. The changes were captured in the form of stories, which I provided the developer near the end of the day for implementation.
- ASIDE: The tool was affectionately named the BAT (which has meaning to the group and organization for which the study is being conducted, but not for anyone else outside the group.). As you can well imagine, as the lead IT person on the team I became known as "Batman", and the developer who no one ever saw during the conference was referred to as "Alfred".
On the morning of the second day, I was able to demonstrate the BAT for everyone with the changes they requested the previous day. Once again, attendees broke up into subgroups to evaluate the changes and further refine the data collection process by analyzing the outputs. By noon, they had a short list of recommended changes, which the programmer implemented over lunch and near the end of the second day the collective group spent over an hour developing a final set of recommended changes to of the BAT input screens. These changes actually reduced the volume of information collected by 18% and significantly simplified the data collection process.
The developer, Alfred, came in early on the third day and implemented all of the recommended changes to date before noon. As a result, I was able to demonstrate a final version to the collective group of MMs and SMs before lunch. The collective group labeled the version of the BAT they saw as an 85% solution and were completely satisfied with progress to date.
The EUs were brought in and met in a separate room on the third day, where they were given an overview of the project, goals, etc. I also had time to put together a training PowerPoint presentation that contained an overview of the process we were using, timeline, and screenshots of the BAT, which I used in my presentation to them. They recommended extremely minor changes to the Graphical User Interface (GUI), and the conference ended on a high note.
At the end of the conference, there was consensus that the five subgroups would continue to collaborate via telephone conferences to document the different aspects of the data collection process more thoroughly, and make final recommended changes to the BAT. All changes would be reviewed by the CG and the senior leader would be the final approving authority.
While the sub-groups were documenting their processes, Alfred was connecting the front-end screens to an Microsoft Access database. Access was chosen b/c all computer Workstations throughout the organization were loaded with MS Office Professional, and using Microsoft Access would be able more people to have access the data for concurrent analysis. Another contributing factor was performance. Since performance was not a huge issue with this tool, Access would work fine; otherwise we would have opted for SQL Server. However, largest obstacle SQL Server posed was limited access to the data would require development of additional outputs, which we were not resourced to develop.

WEEK 3:

Data collection is scheduled to begin on Thursday of week three. The subgroups have until Tuesday to submit change requests, the developer will make them during the day on Wednesday. We will then move the tool from our development server up to a live production server by the end of the day on Wednesday. I should also have the final version of the training manual completed by then as well. I plan to create, maintain, and distribute the user manual in MS PowerPoint (PPT) format.
- ASIDE: I successfully used PPT to create and distribute a user manual for a much more complex system last year and found it to be a very flexible medium and inexpensive to develop and maintain. My total estimated investment into the PPT manual was somewhere around 40 hours for the year. I recently contracted for an outside company to convert my 100 slide PPT into an actual manual in editable format, and it cost around $10K to develop. I would have stuck w/ the PPT format, but the sponsor required something more formal.

JUNE 2006 UPDATE:

There was a two week delay between the end of the three day conference and the date EUs began entering data in the BAT. The time was required to work out the details of the data collection process. Following the three day conference, Alfred began connecting the GUI front-end to the database, which took 7 work days to complete. During that time several teleconferences were held with EUs and MMs to discuss the data collection process, and by the end of the third week the BAT was ready to begin receiving data. Unfortunately the stakeholders were struggling with agreeing on a finite set of locations where data would be collected, and the exact requirement definitions for the data being collected. Although the data fields were locked down, the method by which EUs would uniformly calculate the data entered in the BAT was still up for discussion.
Data collection began at week 5 of the study and took approximately 2 weeks to complete. During the data collection period the CG and Alfred worked to design and implement the four output reports. Report templates were initially designed in Microsoft Excel, reviewed and approved by the CG. These designs were provided to Alfred, who then built them into the BAT along with the functionality to display and print them efficiently. It took a full two weeks to create all 4 reports because of formatting challenges with printing outputs. The formatting issues stemmed from the fact there were 4 reports for each of the 197 locations, which produced 788 pages of data for analysis, and the CG was interested in minimizing the this volume as much as possible.
The first round of data collection was completed at the end of week 7 of the study, and once the CG began to review the data they realized there was a need for several consolidated reports. The decision was made to export the raw data and manipulate it to create summary reports in Excel rather than spend time developing additional outputs for the BAT. As a result of this decision, a significant portion of the remainder of the study was spent manually manipulating and entering data in Excel spreadsheets. Spreadsheet data was reviewed, analyzed and updated through a series of iterations spanning April, May, and June. Finally after nearly 3 months of effort the CG approved the data inputs and the Excel data was imported into the BAT in order to create the final reports.

FINAL RESULTS:

Overall the agile development process helped create and deploy the BAT in significantly less time than traditional software methods would have allowed. Involving the customer base at all levels of system development helped trifold: (1) providing a product that better meets customer requirements, (3) manage customer expectations, and (3) assisted the customer in thinking through the process they were attempting to automate. Agile methods resulted in a better product because customers were given the right to introduce change throughout the entire development process, and their expectations were well managed because they knew exactly what to expect when the finished product was delivered; no surprises. Agile methods also helped the customer work through their data collection process because it provided a GUI early on in the process, and once the customer saw the GUI it shaped their thoughts and paradigms about the procedures they were developing for data collection.
I spent some time discussing the development process w/ Alfred (e.g our developer) and he didn't mind the short development iterations. In fact, Alfred felt it helped keep him on track and the constant flow of feedback presented a significant change over traditional development methodologies where feedback comes at the very end of a long period of development.
After separating BAT development from the survey process, it was determined the total time required to develop the BAT was a little over 6 weeks. This is two weeks over my goal, but still significantly less than traditional methods would have allowed. Two extra days were required to connect the GUI to the database and get all of the field validation correct, and an additional 8 work days were required to properly format the output reports to minimize the volume of printed pages.
And in hind sight, I would have insisted the summary reports created in Excel were included in the BAT in a future version of the tool because a significant amount of time was spent manually manipulating and editing spreadsheets. The BAT could have done it quicker, and without error.

CategoryAgileMethodology