In the past, before Agile, we usually talked about Waterfall, Spiral, and Incremental as three approaches to product development. I feel you can apply both Lean and Agile practices to any of these three approaches. This concept means that project managers need to be “flexible” or “agile” in their thinking and apply the development approach and methods that best fit the specific project. I can envision the same project manager, managing multiple projects, each with a different development approach or even hybrid approaches as the situation demands. I guess you could say project managers need to be “agile thinkers………..”. One size doesn’t fit all, type thinker.
Note: Project management processes and product development processes are distinct. Each has a different focus, which is why it is common to have both a project manager and a product development manager. The product development manager role can be filed by a lead systems engineer, lead software development engineering, business analyst, etc. For a project to be successful, the project manager and the product development manager need to agree on which development approach will be used, or a combination as the situation warrants.
Concerning the three development approaches.
I use Waterfall Development when I have access to the stakeholders and can define the end state/outcomes and requirements to get achieve the desired end state/outcomes at the beginning of the project AND I need to deliver the whole system in one delivery.
The Waterfall myth. There are some that view a key aspect of waterfall as being a rigid, inflexible, non-iterative process. While this may have been how waterfall was implemented in the past, this couldn’t be further from the truth today. Systems Engineering product development is an iterative and recursive process. The system is defined iteratively from the top down; from system, to subsystems, to assemblies, to components. It is recursive in that it is a knowledge-based process where “the devil is in the details” requires one to go back and update previous work based on new knowledge gained as you get more and more into the details. Requirements are defined iteratively as well. Thus waterfall model itself, as a non-iterative development methodology, is a myth and should not be used as an argument to advocate alternative development methodologies.
I use Incremental Development in similar situations as Waterfall – where I can define the requirements upfront — but the system can be delivered in increments, each increment adding functionality and features based on stakeholder priority. The first increment results in a useable system that meets the stakeholders top priority needs. Subsequent increments add to this lower priority needs. I can also use the subsequent increments to include updates to the previous increments. Each increment can be divided into sprints as others have discussed using Agile. A key provision is that you need to define all the interfaces at the beginning of the project so that modules added in subsequent increments will interface properly with the previous increment modules. I address the issue of interfaces for Agile in my blog: Managing Interfaces in an Agile Development Environment
I use Spiral Development when the requirements are difficult to define upfront. Each spiral can be one or more sprints that result in a prototype that can be shown to the stakeholders to get their feedback. It often takes several spirals to nail down the requirements. Once I understand the desired outcomes and can defined the requirements to achieve these outcomes then I go into either a waterfall approach and deliver the whole thing or an incremental approach and deliver the system in increments driven by stakeholder priorities. I talk more about Spiral Development in my paper: Developing Requirements for Technology-Driven Products
It is common to see discussions that talk about using Agile instead of Waterfall. Personally, I don’t equate Agile with Waterfall as two distinct approaches- especially when using the iterative and recursive implementation of Waterfall described earlier. I feel that you can apply lean and agile practices to Waterfall, Incremental, or Spiral product development as the situation dictates.
Having said this, there are some who feel that Agile is a product development process distinct from Waterfall, Incremental, and Spiral. While some would agree that having some agility in your thinking would be a benefit in a waterfall or incremental (or any) process, they do not agree that kind of agility “thinking” makes the process Agile (as in Scrum, XP, etc.). Some feel that an Agile process simply isn’t compatible with Waterfall in that they are two different development processes intended to be used in different circumstances. Agile (as in Scrum) is a very highly disciplined process with specific characteristics that are not compatible with Waterfall. (Note: If those that feel this way are defining Waterfall as non-iterative, I can see why they would think that way.)
Whether or not you believe this, depends on how we each define the various approaches. A key question is how you define Waterfall as contrasted with Agile that makes them incompatible? Scrum, XP, etc. are implementations of Agile, but why can’t you address the real intent of the Agile manifesto using other methods than Scrum, etc.?
What would an Agile/Waterfall hybrid approach look like? What would you have to do to implement waterfall using agile methodologies? To me there is no valid reason one cannot adopt a lean and agile approach to Waterfall. I feel Waterfall gets a bad name because of a misunderstanding of what current Waterfall is as well as because of poor implementations that allow the project to become bloated and overrun with bureaucracy and allow poorly developed requirements.
No matter what your beliefs are in this matter, and no matter which development approach you use, there are some basics you need to follow. You need to understand the stakeholder expectations, you need to translate these expectations into requirements, you need to do design, you need to show that your design addresses the agreed-to requirements, you need to show that the designed and completed system meets the requirements, and you need to show that the delivered system will meet the stakeholder expectations. You also need to allow your team to go back and redo some of the steps based on new knowledge gained as the team progresses towards delivery. This is true no matter which methodology/approach/model you want to call what you are doing………. If your stakeholders don’t know what they need upfront, you need to take the time to work with them so that their expectations for the final outcome can be defined. If these expectations change or evolve over time, your process needs to accommodate that change. Change happens!!
Language is a key issue in communications. To me one of the key differences in traditional waterfall and agile is communications. Sprints are just mini-waterfall interactions or sub-increments or spirals if using Incremental or Spiral development approaches. When those involved in the development of your product are able to communicate easily and frequently during design and implementation, you don’t need big, bad bloated requirement documents.
However, from a contract standpoint there does need to be a set of requirements between the project and the customer as to what the expected outcomes are. These are best communicated in a requirement document that both sides agree to. Agreement to the set implies the requirements are clear, unambiguous, verifiable, and feasible (cost, schedule, technology). If the requirement set doesn’t have these attributes why would you sign the contract and agree to implement them?
I see no reason you can’t use a hybrid approach. For example. I am the lead systems engineer for a large complex project with integrated hardware and software. Part of my project involves developing or procuring the hardware, developing all the software in-house, and integrating everything together. My customer and my overall system engineering process are best classified as Waterfall (following the processes for product development as described in the INCOSE SE HB). My software development team has adopted Agile methodologies. I and the other subsystem leads are the “customers” of the software. We are all co-located in the same general area (some in different buildings, but within several miles of each other). Together we develop top-level “what” not “how” software requirements and define and agree on the interfaces between the software and the hardware and the users of the system. Thus while the overall approach as seen by the external customer is Waterfall, the internal software part of the project is developed using Agile (Scrum, Sprints, etc.) This is what I refer to as a hybrid approach. Why wouldn’t this work? Why would there be incompatibilities between the software folks and the rest of the team?
Actually, I don’t’ see why any of the mechanical subsystems that are done in-house could not use an Agile approach as well. Agile principles can be applied to hardware and not just software. It all depends on the specific implementation of Agile you choose to use.
In closing, I feel all project managers and product development managers should adopt this “agile” way of thinking and use the approach that best fits with the project at hand. One size does not fit all situations. You need to be agile in your thinking to be successful. For more detail on my views of the applicability of using Agile for product development see my blog: Requirements in the Agile World.
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
