3 ms·

The problem I have always had with agile is that it's held up as an "alternative" to waterfall, when in reality it's orthogonal to the two areas where waterfall

The problem I have always had with agile is that it's held up as an "alternative" to waterfall, when in reality it's orthogonal to the two areas where waterfall excels: top-down project planning and contracting / expectation-setting with stakeholders. Agile is something that team programmers really love for its team-building qualities, but stakeholders / project sponsors / angel investors will always think in terms of deliverables and timeline. Waterfall project management is useful because it provides a framework that stakeholders understand. It is also a requirement any time you are dealing with a bureaucracy of any sort, where deliverables and dates will be required. TL;DR don't use waterfall to break down tasks and assign work, use agile for that. Use waterfall to understand and communicate your project from your stakeholder's / customer's point of view.

UK-AL 10y ago
If your team uses agile, but you report using waterfall. Your reports are not mapping reality. It's just lies to keep people happy. Quite simply the order you do things is radically different.
- douche 10y ago
  > It's just lies to keep people happy. That's like 99% of business, anyway. There's a difference between what people think they need to know, and what they actually need to know. Unfortunately, just doing the work isn't enough, most of the time you have to play the game and tick the boxes. The key is not letting that bullshit consume your time.
- ssmoot 10y ago
  It's not though. This is why Agile is such a failure. Because people don't actually read the Manifesto. It doesn't say planning is unimportant. It doesn't say contract negotiation is unimportant. It doesn't say timelines and knowing what you're doing is unimportant. You can and should do all these things. It's amazing to me that Software Developers seem to believe their job is somehow unique and it's just not possible to do simple things General Contractors and real Engineers do every day. Agile is just a set of values that amount to "be pragmatic and flexible". You can totally do that without Scrum and avoiding any sort of planning until the last possible moment. IME actual requirements almost never change in software. They're just frequently not surfaced until code hits the page because little to no due diligence was done on them. And I very very rarely see a case where an issue with fulfilling the client's desires as given couldn't have been surfaced and resolved very early on if someone had just sat down and thought about it for a few minutes before going off and promising something that couldn't be delivered in the time or budget allowed.
  - kod 10y ago
    It's amazing to me that people compare a job that we have 7,000 years of experience with (making buildings) to a job that we have 70 years of experience with (making software).
    - dasil003 10y ago
      Also the construction of physical objects obeys unchanging physical laws. The construction of software is the coalescence of arbitrary logic. Real engineers decry the lack of discipline in software engineering, but I don't think it's possible to impose anything approaching the discipline of physical engineering without radically more constraints, but to do that would require subdividing software into a large number of much more focused domains, and even then, the divisions would be somewhat arbitrary.
  - UK-AL 10y ago
    Oh don't get me wrong, you have planning. You just do everything in a different order. It is radically different because waterfall has distinct phases at a "global" level. Planning(All planning upfront) Implementation(Implement all the plan), Testing(test it all) UAT. Agile has these but does them at a feature level. So the order is radically different. Planning(Plan feature or small groups of features) Implementation(implement feature), Testing(test the feature). You do this over and over again for each feature or little iterations. You may have more loosely defined global plan, but it is not ridged and is expected change as the world changes. Waterfall also encourages to complete parts of the website in distinct phases. Either horizontally or vertically. Complete all the Data access layer, or complete all of the "account functionality". Agile takes small vertical slices. You may want to implement just the login for the account management, but leave the user profile pages until after some other more important vertical slice in some other area like checkout.
- riprowan 10y ago
  The idea that waterfall and agile paradigms aren't compatible is incorrect in my opinion. They are orthogonal. Waterfall is just a paradigm that people comprehend because it maps to reality: 1. First you have to initiate something and define some sort of scope, otherwise, why are you even here? 2. Then you have to refine your understanding with more design 3. Sooner or later you have to actually build something, otherwise 4. Eventually you will have to deliver and implement it with humans in front of it 5. Someone will have to live with it for a while. That's reality, on any project. How you choose to step through these phases - rigidly or fluidly, linearly or spiral-y, or linearly but recursively, doesn't mean that they don't exist in reality. Likewise, agile is a paradigm that developers comprehend because it maps to their reality. If you build software for customers, how you do it is your business, but you will be best off if you can frame it in a way that makes sense to the customer. Especially if that customer is the Department of Defense or some other customer who will demand deliverables on a timeline. I've been building software professionally since the 1990s. As someone who learned programming at a young age, prototyping is my natural way of problem solving, and I think it's intuitive for most "natural programmers." So while I was taught "waterfall" in school and have always used it with my customers, I have always built by prototyping. My customers love it, because on the surface they see a software design process that they expect, and I can communicate my progress with pretty Gantt charts and familiar terminology. YMMV, but it has worked great for me for decades.
sbuttgereit 10y ago
I can definitely endorse this point of view. I've had success with it a number of times now. I think part of the key here is to recognize that you are working on a project (including managing it) in service of those that will consume the results. The mistake I often times see is that people forget that and end up in service of one methodology or another. Too many times I see a project manager types that can't reason out the distinction between the mechanics of a given project management process and the goal that process is setting out to achieve through the mechanics. Once you focus on what you're trying to achieve in any process, rather than how you're trying to achieve it, you can adjust your process to be optimal to the team/customer/etc. It's not all mutually exclusive and there are rarely benefits for being loyal to a methodology for purity's sake.
ap22213 10y ago
Until recently, 'Waterfall' was used to describe a process anti-pattern. At least, it was prior to 2010 or so.Software engineers have known for decades that iterative and incremental processes (spiral, UP, etc.) work best to manage risk, to prioritize important requirements, and to align with user goals. I'm not sure exactly when people started to use 'waterfall' as a real process. Recently, I've started educating my team on OpenUP (a simplified RUP), and they were surprised by it. I guess they imagined that software management didn't exist before SCRUM.
- collyw 10y ago
  There were plenty of successful projects written using waterfall. Not a great fit for all, but not an anti-pattern.
  - ap22213 10y ago
    You're just making things up now. Proof?
    - riprowan 10y ago
      Your proof is found in the entire canon of software engineering prior to the late 1980s, when the concepts of "prototyping" and "RAD" became feasible. When code was written by hand with pencil and paper, then translated to punch cards, "prototyping" was an exorbitant amount of work. Moreover it added little value, as the first two entire generations of information systems were little more than electronic implementations of very-well-understood business processes. I studied systems analysis / engineering in the late 1980s. At the time, the entire paradigm of software engineering was waterfall, with the exception that the idea of prototyping was just getting started as something you could do iteratively in the "design / build" boundary.
    - collyw 10y ago
      You really think there were no successful software before Agile came along? https://www.quora.com/What-are-names-of-successful-projects-using-the-waterfall-model https://www.quora.com/What-are-names-of-successful-projects-...

UK-AL 10y ago

If your team uses agile, but you report using waterfall. Your reports are not mapping reality. It's just lies to keep people happy. Quite simply the order you do things is radically different.

douche 10y ago
> It's just lies to keep people happy. That's like 99% of business, anyway. There's a difference between what people think they need to know, and what they actually need to know. Unfortunately, just doing the work isn't enough, most of the time you have to play the game and tick the boxes. The key is not letting that bullshit consume your time.
ssmoot 10y ago
It's not though. This is why Agile is such a failure. Because people don't actually read the Manifesto. It doesn't say planning is unimportant. It doesn't say contract negotiation is unimportant. It doesn't say timelines and knowing what you're doing is unimportant. You can and should do all these things. It's amazing to me that Software Developers seem to believe their job is somehow unique and it's just not possible to do simple things General Contractors and real Engineers do every day. Agile is just a set of values that amount to "be pragmatic and flexible". You can totally do that without Scrum and avoiding any sort of planning until the last possible moment. IME actual requirements almost never change in software. They're just frequently not surfaced until code hits the page because little to no due diligence was done on them. And I very very rarely see a case where an issue with fulfilling the client's desires as given couldn't have been surfaced and resolved very early on if someone had just sat down and thought about it for a few minutes before going off and promising something that couldn't be delivered in the time or budget allowed.
- kod 10y ago
  It's amazing to me that people compare a job that we have 7,000 years of experience with (making buildings) to a job that we have 70 years of experience with (making software).
  - dasil003 10y ago
    Also the construction of physical objects obeys unchanging physical laws. The construction of software is the coalescence of arbitrary logic. Real engineers decry the lack of discipline in software engineering, but I don't think it's possible to impose anything approaching the discipline of physical engineering without radically more constraints, but to do that would require subdividing software into a large number of much more focused domains, and even then, the divisions would be somewhat arbitrary.
- UK-AL 10y ago
  Oh don't get me wrong, you have planning. You just do everything in a different order. It is radically different because waterfall has distinct phases at a "global" level. Planning(All planning upfront) Implementation(Implement all the plan), Testing(test it all) UAT. Agile has these but does them at a feature level. So the order is radically different. Planning(Plan feature or small groups of features) Implementation(implement feature), Testing(test the feature). You do this over and over again for each feature or little iterations. You may have more loosely defined global plan, but it is not ridged and is expected change as the world changes. Waterfall also encourages to complete parts of the website in distinct phases. Either horizontally or vertically. Complete all the Data access layer, or complete all of the "account functionality". Agile takes small vertical slices. You may want to implement just the login for the account management, but leave the user profile pages until after some other more important vertical slice in some other area like checkout.
riprowan 10y ago
The idea that waterfall and agile paradigms aren't compatible is incorrect in my opinion. They are orthogonal. Waterfall is just a paradigm that people comprehend because it maps to reality: 1. First you have to initiate something and define some sort of scope, otherwise, why are you even here? 2. Then you have to refine your understanding with more design 3. Sooner or later you have to actually build something, otherwise 4. Eventually you will have to deliver and implement it with humans in front of it 5. Someone will have to live with it for a while. That's reality, on any project. How you choose to step through these phases - rigidly or fluidly, linearly or spiral-y, or linearly but recursively, doesn't mean that they don't exist in reality. Likewise, agile is a paradigm that developers comprehend because it maps to their reality. If you build software for customers, how you do it is your business, but you will be best off if you can frame it in a way that makes sense to the customer. Especially if that customer is the Department of Defense or some other customer who will demand deliverables on a timeline. I've been building software professionally since the 1990s. As someone who learned programming at a young age, prototyping is my natural way of problem solving, and I think it's intuitive for most "natural programmers." So while I was taught "waterfall" in school and have always used it with my customers, I have always built by prototyping. My customers love it, because on the surface they see a software design process that they expect, and I can communicate my progress with pretty Gantt charts and familiar terminology. YMMV, but it has worked great for me for decades.

sbuttgereit 10y ago

I can definitely endorse this point of view. I've had success with it a number of times now. I think part of the key here is to recognize that you are working on a project (including managing it) in service of those that will consume the results. The mistake I often times see is that people forget that and end up in service of one methodology or another. Too many times I see a project manager types that can't reason out the distinction between the mechanics of a given project management process and the goal that process is setting out to achieve through the mechanics. Once you focus on what you're trying to achieve in any process, rather than how you're trying to achieve it, you can adjust your process to be optimal to the team/customer/etc. It's not all mutually exclusive and there are rarely benefits for being loyal to a methodology for purity's sake.

ap22213 10y ago

Until recently, 'Waterfall' was used to describe a process anti-pattern. At least, it was prior to 2010 or so.Software engineers have known for decades that iterative and incremental processes (spiral, UP, etc.) work best to manage risk, to prioritize important requirements, and to align with user goals. I'm not sure exactly when people started to use 'waterfall' as a real process. Recently, I've started educating my team on OpenUP (a simplified RUP), and they were surprised by it. I guess they imagined that software management didn't exist before SCRUM.

collyw 10y ago
There were plenty of successful projects written using waterfall. Not a great fit for all, but not an anti-pattern.
- ap22213 10y ago
  You're just making things up now. Proof?
  - riprowan 10y ago
    Your proof is found in the entire canon of software engineering prior to the late 1980s, when the concepts of "prototyping" and "RAD" became feasible. When code was written by hand with pencil and paper, then translated to punch cards, "prototyping" was an exorbitant amount of work. Moreover it added little value, as the first two entire generations of information systems were little more than electronic implementations of very-well-understood business processes. I studied systems analysis / engineering in the late 1980s. At the time, the entire paradigm of software engineering was waterfall, with the exception that the idea of prototyping was just getting started as something you could do iteratively in the "design / build" boundary.
  - collyw 10y ago
    You really think there were no successful software before Agile came along? https://www.quora.com/What-are-names-of-successful-projects-using-the-waterfall-model https://www.quora.com/What-are-names-of-successful-projects-...