Waterfall Method-courtesy of Wikipedia.org

Reflections on the Waterfall Method of Software Development

I was recently reflecting on the Waterfall Method of Software Development, and enterprise-level Intranet projects I had designed as a business consultant for a custom programming company in years gone by. Intranets are restricted web-enabled assets of a company that are only accessible to authorized users who navigate strict security precautions to gain access. We used to think of the intranet as being a private part of the Internet. Today we think of it more simply; you are given access to the apps you need to do your job.

Thinking about the project management process we used back then, (the Platinum Process Continuum), what really struck me is how the CabForward℠ business model has improved on that process. And, certainly, it isn’t just CabForward℠ that has made these improvements, it’s much of the software development industry. This improved process resulted from the combination of Lean and Agile methodologies which laid the groundwork for a better fitted project management system for software development.

Waterfall Method-courtesy of Wikipedia.orgIt started with the Lean manufacturing process turning the old Waterfall process on its ear in the manufacturing industry. Software developers tried to adapt the Waterfall process to their industry, because, at the time, it was the dominate process for project management. In the Waterfall process, the project management team spends a lot of time before the project begins to try to understand, document and plan everything that needs to be included. Client meetings, interviews, surveys, and all types of information gathering goes into the front end so sketches or mock ups of work flow can be produced and approved by the customer. Then, development begins.

For a software project, the project manager then assembles a team of coders with the required skills, and approved plans in hand, guides the team to create the project according to the mockups. The project is developed at whatever level of speed the budget provides. Sometimes the project team is large enough that work is commenced on several parts at the same time, and then zipped together toward the end of development. Then it is rolled out to the customer. The project often takes months.

Parallel DevelopmentIt is at this point that a lot of software projects fall apart and fail to meet customer needs, even though the deliverable is exactly what is portrayed in the plans. That’s because the team has been working on developing the materials agreed upon at project start up, but the customer has been dealing with change in the industry each and every business day. Business needs have evolved, but the original project concept did not. What is delivered to the customer is already out of date!

Change Control Process

The project management process we used back then had a well structured Change Control Process in an effort to make software development more reactive, get the customer more involved in the development process, and help reduce the rate of failure at the end of the project. I had experienced these failures in my own teams’ projects, and searched for ways to keep the customer more involved, such as giving the customer access to the website as it was being built so they could be “in the loop” at every step of production. Still, it’s the Waterfall process itself that isn’t a good fit for software development; it was created for manufacturing, where change happens at a much slower pace.

Ruby on Rails is open source softwareThat’s what excites me about how we do business at CabForward℠ today. We want, in every case, for the project to be successful for us and the customer. We use a Discovery Session to fully understand where the product is headed and to identify and “point” user stories. We provide Project Management software that permits the product owner to be involved in the process all along the way, see exactly where we are with the project, and interact directly with the developer(s).

We use free Open Source tools so there are no software license fees or costly mandatory vendor updates in the future. That reduces the cost of development significantly, and is why we set out to be “Ruby on Rails in Austin” right from day one of our start up. We grew, of course, into a polyglot shop with multiple software disciplines, and are now also deeply ingrained in iOS for mobile applications.

We encourage our customers to be involved as much as possible during each step of the development process, so changes and revisions can be incorporated along the way. That is why we choose to do projects in short sprints of one or two weeks, so the customer gets a deliverable at the end of each sprint, whether it is a new feature or enhancement of an existing function. It is measurable, and gives the customer a means of evaluating results on a much more frequent basis. That is why we like lean and agile methodologies. It fits the way we like to do business.

CabForward℠ strives for successful engagements in every instance, and seeks ways to exceed the expectations of our clients. As we grow our business, learn about new tools and practices that help us be more productive, and gain more maturity, we become a better Strategic Technology Partner for our customers.  We are always on the lookout for advances in our industry, areas of improvement that can enhance our overall value, and increased transparency that can better ensure an angst-free  experience in every engagement.

Have you worked with us? What did we do well, and where did we disappoint? How can we improve your overall experience in using us as your Strategic Technology Partner? We value your feedback. Please leave us your comments below.

Your Name (required)

Your Email (required)



Your Message