Waterfall is still my preferred method when project deadlines are fixed, or when multiple teams are involved with multiple software components needing to be integrated. In Waterfall, the developer and the customer agree early in the development lifecycle on what will be delivered during the requirements phase. This is more transparent at the initiation of the project, which makes planning easier. Progress is straightforward, measured at set milestones, and the scope is determined well in advance. An obvious challenge with this methodology is gathering the all-inclusive requirements. (In Government, requirements are frequently imposed on us by such things as legislative mandates, federal regulations or the installation of an integrated software packaged solution, all of which provide additional upfront guidance.)
So with the aforementioned bias, I began to investigate Agile Development as a supplemental toolset in the development arsenal. I was fairly new to the Development role when I was asked by my staff, “What are your thoughts on Agile development methodology?” I honestly was still learning the nuances of Waterfall Methodology and I had not yet given much thought to Agile. Since I had only a primitive knowledge of it, I utilized my well-honed executive skills and asked, “What are your thoughts and how would Agile benefit us?” Finding out everyone in the room had a different response, I recommended training and each of us became Scrum Masters.
Just as we had done in 1985, manufacturing HVAC systems, Agile Software Development allows for a shorter production schedule
Until then, I had always held the opinion that Agile was the “Wild West” of development methodology. I thought it lacked central oversight, accountability and specific milestones to gage progress. Even as a new Scrum Master, I found the opposite to be true. Thus, I began challenging my experiences with assembly line production, specifically when product delivery was on a tight timeline.
One of our differentiators at the HVAC manufacturing plant where I worked just after college was our ability to engineer and produce small custom orders in a very limited time frame. The sales team would take a custom order and tell us the requirements including our delivery deadline. Normally a hotel had ordered a standard model and during construction something changed in the building design which meant the model they had ordered no longer fit (nor any other standard model). In order to meet the closing construction timeline they needed premium service.
We learned that providing a prototype early in the design process sped up production of the finished product. We would begin by taking our standard product models and repurpose those parts where we could. One big difference from our standard production process was our inclusion of the assembly line team early on in the design phase. These were our “customers” who were going to build the unit, and we knew their input would be valuable to our timeline. We needed them to assist us in designing a unit that they could actually assemble in production. We knew that with a limited timeframe and small quantity of product, we did not have time to thoroughly work out assembly line issues in the normal manner, which meant including input from the assembly line team towards the end of the process in a pre-production final review-- Too late to quickly make design changes. We changed our process instinctively, simply to allow the team to work on rushed timelines.
Just as we had done in 1985, manufacturing HVAC systems, Agile Software Development allows for a shorter production schedule. This is because the process involves the developers who are going to build the code, early in the process. I feel the largest difference between Agile and Waterfall is this continuous and early interaction between IT development staff and the customer, a noted strength of the Agile approach. Having this recurrent checkpoint for interaction aides us in minimizing the requirements challenge I mentioned earlier. Developer engagement occurring early in the process allows the developer to assist (often help direct) the customer with requirements. So they jointly design a product and produce the prototype similarly to how I described was done in my manufacturing days.
My early experience in manufacturing taught me to recognize when differentiated process is needed. Then I discovered that creating a tangible prototype and getting constant customer feedback from it is essential to providing a useful and quality product. I learned from a combination of applying my common sense and allocating their sources needed to meet customers’ expectations (including increased speed). Agile certainly is not a total replacement for Waterfall, simply another powerful option in the development toolkit. Presently at the State of Nebraska, some of our development teams have already begun using Agile. In organic fashion the methodology spreads from one team to the next, a campaign based on common preference. Developers and customers like it.
