Agile & Waterfall Background

by Kurt.Simon

Waterfall

Waterfall

Large extensive software development projects have typically used the waterfall development methodology. Its uses defined milestone gates to proceed onto the next phase of development. For large projects this is necessary to ensure all elements are in lock step with each other before they are integrated into the larger system. Agile development methodology came along in response to the need for quick deployments and stakeholders that are not completely sure what they want until they see it. I am a Lead Systems Engineer on a very large multi-year project to deploy image processing software for a satellite ground system. The complexity, size, and number of systems and subsystems being developed and needed to integrate together made waterfall methodology a requirement. Many elements need to integrate together on fixed schedules for coordinated testing efforts before product deployment. Although the schedules for each element and subsystems may be on a slightly different time line, they need to converge at each level of the system’s milestone phase. This is particularly important for interface success and coordinating end-to-end testing. As part of this new development, a new Service Oriented Architecture (SOA) framework was going to be needed to support the system messaging between subsystems and security between the various applications. Because SOA was going to be the foundation for the development and required for any integration and testing between elements and subsystems, it was recognized early on that it needed a faster development cycle to deployment. I would like to share some experience and lessons learned in trying to manage a project using agile and waterfall software development.

Life Cycle 101

It is important to realize that in project management we like to use the project phases of Initiation, Planning, Execution, Control, and Conclusion. But engineering follows different project life cycles usually described by the following phases or slight variations on these terms: conceptual, requirement generation, preliminary design, detail design (critical design), development/implementation, test, and deployment. A brief distinction between waterfall development and agile is that waterfall takes the entire system or subsystem requirements through the life cycle in entirety with major milestone reviews used as gates for approval into the next phase. At these milestones, engineers in charge of the interfacing elements, subsystems, or systems have chances to review and negotiate so they can all integrate smoothly. Agile development works on small amounts or groups of functional requirements which can complete a life cycle in one month sprints. Whatever requirements weren’t completed or failed testing are worked on the next month with another group of requirements.

Agile

Agile

Each month allows a re-prioritization of requirements to work on. There are typically not major milestone reviews in Agile development, only peer reviews. The intent, as stated earlier, is for quick deployment and would be counter-intuitive to “slow down” for a major review.

Over the course of a few articles, I would like to share some lessons learned in managing the two types of software development life cycles. The first topic that I would like to discuss will be scheduling.

(To be continued)

Agile & Waterfall

  1. Agile & Waterfall Background
  2. Agile & Waterfall Scheduling and Sprint Planning

No related posts.

Leave a Comment


{ 2 comments… read them below or add one }

bbozzuto November 4, 2008 at 1:43 pm

I like the direction of this topic so far, but I take issue with one part of it.

“The complexity, size, and number of systems and subsystems being developed and needed to integrate together made waterfall methodology a requirement.”

Was this a requirement because management felt it was or because the team was not comfortable using an enterprise wide deployment of an Agile framework? There certainly is additional complexity and overhead introduced when dealing with multiple subsystems, but I’m curious why you say that would require a waterfall execution.

I am looking forward to hearing more about your story!

Reply

bbozzuto November 4, 2008 at 7:43 am

I like the direction of this topic so far, but I take issue with one part of it.

“The complexity, size, and number of systems and subsystems being developed and needed to integrate together made waterfall methodology a requirement.”

Was this a requirement because management felt it was or because the team was not comfortable using an enterprise wide deployment of an Agile framework? There certainly is additional complexity and overhead introduced when dealing with multiple subsystems, but I’m curious why you say that would require a waterfall execution.

I am looking forward to hearing more about your story!

Reply

Previous post:

Next post: