4 ms·

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

by UK-AL 11y 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 11y 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 11y 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 11y 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 11y 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 11y 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 11y 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.

by UK-AL 11y 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 11y 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 11y 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 11y 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 11y 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 11y 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 11y 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.