This article addresses a process where a team moved from a traditional waterfall model to using agile elements in order to deliver a product to a government agency. It talks about typical problems that come up in a transition to agile, complications from distributed teams, and the advantages and disadvantages of the process for government or nongovernment clients.
In my previous engagement, I worked on a cross-functional team including project managers, developers, testers, technical writers, functional analysts, and user groups tasked with delivering a product, a pharmacy application, to our customer, a government agency. Our team transitioned from a traditional waterfall model to a project where we used elements of agile.
Agile values interactions over processes, among other things, and time to delivery is quicker because you complete small chunks and get feedback sooner so that you have the ability to change in a speedier time frame.
In our project we were able to complete small chunks with customer feedback, but the daily standup calls to report status and any issues that were preventing people from moving forward were not done. In the approach we took using elements of agile, we had requirements, design, and testing occurring collaboratively and simultaneously so that the deliverable could be produced in a quicker time frame. Normally in true agile fashion, the story would be done in a day or so. Ours took a week.
What we did first for the government agency was articulate the requirements. There were approximately forty requirements that had to be implemented in this particular patch, so the function point estimate was medium to large. The requirements were gathered through stakeholder calls, user group meetings, and our own understanding of the application under test. There were numerous disagreements among the team members about the right way to address the issues that occurred.
Once a flaw in the requirements specification document or an unclear requirement was recognized by one of the stakeholders or a member of the user group, a developer was consulted to provide a design solution, which was then reviewed by the team after being approved by the user group. The code was then implemented or a decision was made to put it on a tracking spreadsheet for a future release. We would then send this to some of our test sites for review. At one point there were issues about the scope of the project, which created tension among the team members and had to be settled before moving forward.
Afterward, we conducted peer reviews of our user stories and requirements specification document. The requirements specification document was large, at approximately twenty-five pages and forty technical requirements that had to be implemented. It took several weeks to be reviewed by the stakeholders. Once a baseline requirements specification document was completed, we proceeded to develop test cases. Again, a peer review was completed on the test case document.
At the same time, developers were coding the solution and producing a software design document. This document was also peer-reviewed. After all documents were peer-reviewed and the code was internally tested, we submitted it to an independent verification and validation team. At the same time, we ramped up our use of elements of agile by having our user acceptance testing done in sprints without the daily standup calls.
Each sprint was done in one-week increments in which we provided a user functionality test case document and held calls on a daily basis with the test sites. After our user functionality testing was done, our approach became more similar to agile because as new issues arose, code changes were completed and new versions or chunks were sent out. Rapid turnaround time was expected, meaning within three to four days, until we reached the time frame when we had to get test signoff from our production test sites.
There was a lot of tension on the team due to having to send out new versions in timely releases because in this particular agency the final product had to be released in six months. Another issue that affected the team members was that we all worked remotely throughout the United States, so we could not get into a conference room and iron out the problems that arose and clear up any misconceptions or misunderstandings.
Completing testing using elements of agile in this manner led to greater efficiencies of scale and reduced our time to delivery. However, I was not the project manager, so I could not estimate how much money was saved.
The advantages to this approach were that we received green flags from the government agency for releasing our product before the deadline. Everyone involved had buy-in to the product.
The disadvantages to our approach were that the project manager never had true buy-in from the lead developer on the project for the daily standup calls, which meant we did not have them. Often the developers were working in isolation from the rest of the team, which led to arguments and disagreements.
This is a detailed example of how agile elements can be applied to any type of software project, and the advantages and disadvantages that can come with this approach. Hopefully, government and nongovernment agencies alike can benefit from my experience.
