The Waterfall Model works because you know exactly what the solution is before you start coding. That is the whole point of the Requirements Specification and there is no reason today NOT to know everything up front because we have Big Data to draw from: the Business Knowledge Domain, Functions, Tasks, and even Software Patterns. It may take 12 months to understand the Requirements Specification from the Requestor/User, but the maintenance is almost zero because the coding is a translation from the Spec language to the Computer language and easily verified. And the program will work almost flawlessly from day one for the next 5 years or more. Move on to the next project. To start coding before you know what the customer wants is a terrible way of working that leads to the software crisis. The crisis is that the software worldwide is unreliable and bordering on collapse. The customer will also keep adding wants to the existing software as it reveals more possibilities without increasing payment. This is never ending. By documenting exactly what the customer wants (even if it takes 6 months or more) results in a solution and program that is more robust, resistant to change, and avoids bloat. I'm guessing you never tried the Waterfall Model so you have no experience with it. The weakness with the model is the customer: Are they willing to discuss their business requirements to the minutest detail over the next 6 - 12 months before coding starts? Most will see the delay as falling behind the competition and refuse. The others will gamble on a 9 year ROI and they will win if you've done your job properly. The rest may be flattered that someone is so interested in the business that they'll happily talk about it for months on end. And to see it, not only documented in detail, but actually working in practice, is a massive ego boost. And the kicker is bragging rights that it is bug free (mostly), requiring little to no maintenance costs for the rest of its life cycle. Such reliable software is worth far more than agile programming promises. You don't come up with the solution, the customer does because they know what the program must do. If they don't, then you need to get them to find a solution by asking business questions. You may offer alternatives based on software models, but ultimately it is the customer who decides what the software will do. The Software Requirements Document simply shows the customer you understand their solution, that is, you now know how their business works well enough to automate specific parts of it and interface them into their business model. Once they sign off the document, you can now establish a Plan and Design Document to meet the Spec and enlist programmers to code the solution, as Designed, from the Spec, according to the Plan, and using Module folders to track their progress. Finally, the staff will need training on the menu, forms, and data I/O.

Hahaha i love this 🥹

You Sir should be knighted

🤣

couldn't agree more

😅😂 💯

The scary thing is that it works. The whole world runs on software written like that. For all these companies know they are using the state of the art of software development methodology.

You can tell it will be a train wreck from "etimated 3h-15d", then "promise to deliver story points". You can't convert between time and story points, that's the point of them. It's one of those red flags like thinking that more people means less time.

Let's just be clear on terminology here 😉 What you described may have been called agile, but it is very far from agile based on the definitions from the people that invented the concept of "agile development" agilemanifesto.org

@@ContinuousDelivery I think we have all read the manifesto here, but what do you propose that we do? Working in these organisations is like working with flat earthers. No amount of evidence or rational arguments will change their minds. I don’t even think a true agile company disrupting an entire market is going to convince anyone, since there are too many other confounding factors for market success.

@@salvatoreshiggerino6810 choose the org you work in, you live only once. Let evolution take care of the rest.

Yeah - I was kinda surprised with the immediate dismissal of wireframes. Huh? I guess wireframes aren't done by agile? Weird moment, and totally unexplained for us non-initiated.

Yes you can, but it takes a different mindset, a different understanding of what SW dev is really about and so, how to do it. I"d argue that SW dev is a process of learning, and that what we do is learn enough to come up with a design that works for the problem that we are trying to solve, that means that we need to organise to learn. Waterfall works against learning, because the best way to learn is to try ideas out, so effective teams organise themselves to be able to try ideas out, learn from what they find and do more of what works and less of what doesn't. That is not just the "agile" approach, but is also how science and engineering work!

Yeah... you can. Continuous discovery and continuous delivery. Instead of planning everything up front, you first identify the problem, test solutions (ideally solutions that don't require any code) and start building the minimum solution. And you don't stop there, you keep on doing the discovery work, constantly testing the product and new ideas with users. Agile is not doing all the steps of waterfall in repeated increments, it's doing the discovery and delivery all the time.

"without a bare minimum of" --> An engineering principal for over 2000 years....for a reason

"You cannot escape waterfall" - The problem is the timeframe and the false assumptions around designing large systems upfront (one of them is assuming that your design is correct without testing it out and another is that it will rarely change, just to name a few). When you make that timeframe smaller (not months, but days) you get feedback faster, you can improve and evolve in better directions and when you do a mistake (not "if" - you will do mistakes), you can fix and learn faster.

That sounds more like Feature Driven Development, which fixes scope and flexes time as an approach to agile software development.

The last step would be to stop calling any methodology (even XP) "real agile" :)

Yeah it's basically the SEO market for management.

Joke's on the people paying so-called "gurus", who never wrote a line of code in their lives, to teach them about Software Development Lifecycle...

Nailing down the requirement is a key waterfall skill. It's not impossible, or even particularly hard. But if you haven't got the discipline to do it I suppose you need Agile.

@@_Mentat And it doesn't work. Latest when you spot a hole in the spec the customer will use it to fill the hole and redirect the requirements. And there you go: Change. Agile was invented to work with the real world of (pure) SW development. If you develop close to hardware it may be different, because HW has to be frozen on some point for mass manufacturing.

@@kevinfleischer2049 Our customers sign contracts. They could change the requirements but it would cost them. Mainly they don't. Usually we have a succession of contracts with the same customer and if they want a change or additional functionality it becomes part of the next contract a couple of years later. We're basically doing the same thing over and over again for different customers; "a hole" is not likely.

@@_Mentat agile is not a workaround to not been disciplined enough to nail down the requirement, it is a way to work with constantly changing environment and knowledge (practically, with the real life). Numerous projects have failed as the whole problem they were trying to solve was not actual anymore while they were implementing the solution for it. From the other point, some products have reached huge success by being able to transform dramatically as soon as they observed changing environment.

@@kevinfleischer2049 even for hardware, environment may change dramatically. That's why you want to prototype something first and see user's feedback before enabling full-scale manufacturing of the product. Yes, cycles can be longer, but the whole idea - as quick feedback loop as possible, is the same. And this is especially true now when firmware for a lot of devices can be loaded any time.

Exactly. It is very common for customers, whether internal or external, to not fully understand their own requirements. It is not easy to imagine the details of something they have not seen before.. So if you are not building a trivial variant of some standard existing software, you need to include a learning process along the way.

@@ComradeOgilvy1984 Yep. And there's rarely any "budget" for that learning process.

I've run into this problem multiple times. The end user doesn't know what they want. They have a general idea but haven't thought through to completion what it is they want built. That's where agile requirements come in. As developers we make our best guess what the customer wants and build a prototype quickly. Get feedback and iterate again. Software iterations can drive out ambiguities in requirements. You don't have to determine everything up front. Ambiguities can open up opportunities that you couldn't see earlier in the process. Ambiguity isn't always a bad thing.

@@deanschulze3129 Exactly. If you press a customer for the details of what they want, they will tend to try to explain in terms of standard things that already exist, regardless of how mediocre the standard things are for the problem on hand. Now, that is not necessarily a terrible mistake as a beginning point if you plan on improving iteratively, but it points to why trying to make detailed requirements early tends to be counterproductive -- you exhaust your customers and stakeholders early, and they quickly get frustrated when things do not turn out well. Better to start off with the mindset that early deliveries will be BOTH good and mediocre, but improvement is inevitable, and THEN it makes sense to press for detailed feedback and guidance.

Don't leave QA out of that approach you are working on. Most of the problems in the industry could be improved by intelligent QA teams focusing on set-based methods of testing - i.e. develop tests that will work REGARDLESS of the implementation or language or project methodology or team structure. Do that, and you have a control gate against the problems with code, stakeholders, processes, bad design, etc. QA is the most important part of the process, and TDD is not the answer (sadly, I wish it was).

I understand the gripe, but i think the implied resolution here is “just let the developers be the local gods of everything and it’ll all just work itself out”. As a developer who has enough trouble keeping up with the current cutting edge of implementation and process best practices, I certainly don’t think that’s very sustainable either. I think the path forward for companies is a model where everybody has their strengths and is respected for the values they bring to the team, but where that input is still not ironclad. If I’m strong in React and CSS, then maybe I can drive the UI discussions but still be receptive to product when something isn’t matching the customer’s mental model of the domain. It i’m an expert in distributed cloud architecture, then I should still be responsive to the idea that I could be building a system that’s hard to work with to satisfy overkill performance expectations. The problem is that today’s waterfall-in-disguise status quo is fundamentally driven by commitment to unreasonable schedules, and that makes people fearful and prone to finger-pointing whenever anything goes differently than the ill-conceived plan, and that’s the kind of the problem that leadership creates and solves.

I've always loved the Cargo Cult comparison. There are literally (figuratively, if you must) rituals, and they're called as such. If we're doing the rituals, it must be Agile; if we pretend to run an airport, then the cargo planes will come back.

It's certainly a cult. They talk of ceremonies, rituals and artifacts. And the believers have religious fervor. The Scrum Masters and Product Owners support it like their (working) lives depended on it. Which they do.

This guy gets it

We need back those traditional roles: UI/UX, business analysts, Software Architects. We need it for our own sanity. We need it and the business needs it, there's no shame in that.

Haha, a lot longer of course. Industry average is $50 per line of code. NASA pays $1,000 per line of code. That's the cost if you want defect free code.

Yes, I think that there is a kind of "new speak" around waterfall thinking that attempts to hide it. Not sure if it is on purpose, but it certainly exists. Most companies that I work with still divide dev into a series of steps or stages, with very little iteration or feedback between them. Whatever you call it, that's a waterfall!

What you described sounds like 'agile ', and by that, I don't mean a methodology, but more of a principled approach based on circumstances

@@closeredge5198 no, that's common sense.

@piotrd.4850 and agile principles DONT include common sense ideas ( empiricism, inspect and adapt, collaboration etc) ???

I try maintaining that the vision in the Agile Manifesto should always be on our mind when we do a process. I get a lot of shrugs and go back to the same JIRA crap and stale execution. Team and leads complain about lack of processes, prioritization and coordination...but no one is willing to change or "rock the boat". God I hate "Agile" and hate JIRA even more.

Agile is for one-pizza-team internal organisation. It is NOT Project Management methodic, much less PRODUCT management.

I'm am with you on this. 40 years on software projects and it's black and white. Early waterfall projects in my career were successful, latter day Agile projects are truly awful. I feel sorry for young developers that haven't known anything but Agile, they have no clue there's a better way.

It's all about title-case Agile, that is a simulacrum of actually being agile. That enterprise-type Agile camouflages command and control under some activities that mimic flexibility by giving minimal self-organization and ownership practices to employees.

"I feel something has happened where we" --> A lack of qualified engineers, allowed management to entertain the notion, that those skills could be replaced by process. Agile makes that promise. Not skilled in the SCIENCE of estimation? No problem, use points. Not skilled in grasping requirements? No problem, use use cases and cycles. Now, the industry is overrun with "developers" instead of engineers, and we still have ZERO empirical evidence, that most agile methods, ACTUALLY meet the claims of their proponents.

Sorry, but that is simply untrue, I worked on several projects that were run without there being any iteration, in fact in my experience that *is* the norm for waterfall projects. Structurally it is quite difficult to avoid. If you spent 3 months in analysis and 4 months in design, and then a developer says "this is wrong" what is the mechanism to correct the analysis or design? If you spent 6 months building the system and then during testing, find that the architecture is so bad that it makes the system too slow to use, again, what is the mechanism defined in most Waterfall projects to correct this, without redoing the whole waterfall. All of these are real world examples, from projects that I have seen myself!

@@ContinuousDelivery Well, that only means that your experience has been bullshit

Well said,they sell lies and yellow stickers to the wall.

I could stand that process taking 6 weeks right now. (Our orga. Is struggling to deliver known content every 3 months)

No, waterfall is terrible. In the paper that describes it, the author wrote to not practice this.

This "law" treats people as non-sentient, pretty much.

@@piotrkozbial8753 The system doesn't really allow and incentivise individualism, virtually by definition.

When end users won't do the work to create good requirements up front then developers can use software iterations to hone in on what the requirements should be. Get feedback and iterate again. This approach may not be ideal but it works.

I think that’s why people are asking for waterfall to return. It’s not that they wouldn’t rather be agile, it’s that they want the people at the upper tiers of the waterfall to have some accountability that is missing from the fake-agile waterfall.

Also unlike fake-agile waterfall, traditional waterfall is quite a lot more empirical and iterative. You build scale models of your structures and test them in wind tunnels and wave tanks and the like, then go back and refine them before passing the design down the waterfall and build it for real.

No it does not, only prescription from Scrum is that the sprint should not be longer than 4 weeks.

Scrum is not what we could call agile. That is the problem, scrum making itself call it agile. Fixed sprints, stand up meetings, retrospectives (where every "process improvement" only adds more and more burocracy (templates for everything, algorithms for doing everything, more and more deliverables, terminations criteria, etc etc etc)). Jesus, what a shit

Nope! Agile is "I think this is the right answer, but it may be wrong, how can we find out?" - which is also how science works! Waterfall is "If I think really hard I can get the answer right first time" which is how nothing ever works.

@@ContinuousDelivery nope. I said the foundation is organized with waterfall. The other %95 is agile. Unless you subscribe to start coding and then we'll tell you what we want. Retrofitting or planning the foundation after the fact is how kids plan

Exactly

I still remember the time some of the CS capstone students complained to the faculty that the structure of the capstone class enforced a waterfall development method since the first deliverable was a requirements doc, the next deliverable was a risk analysis, etc.. They were not happy about that but they also didn't have much of a retort.

I certainly think that's a factor, but the accounting practices and budgeting practices are just another facet of the same overly naive approach to, in this case, business. This is the bureaucratic response. I think it may be possible to get away with such inefficient, "distanced from reality" approaches for things that aren't exploratory and creative (like software), but even for those things it makes everything slower and less efficient. For exploratory and creative problem solving disciplines, like SW dev, it is death. I don't know of any great SW that was built this way. Read the "Mythical Man Month" (Fred Brooks saying the same things in the 1970s, or "Rapid Development" (Steve McConnell saying the same things in the 1990's). This bureaucratic approach is naive and completely misunderstands what SW dev really is.

Sadly this kind of teaching is still happening, usually from people who have never built software for real.

What the teacher meant is your way wouldn't scale, but you have to learn a scalable methodology even though a school project doesn't need it, because in the real world you will need it.

@@_Mentat that's funny.... I talk about being at school (40 years ago) and you assume I'm still there or, at least, only just left. :)

@@edgeeffect Nothing in what I wrote implied you are currently or were recently at school.

....as result, it creates permament 'crisis mode' and discourages long term thinking and investment.

it doesn't matter what system you use

Not true. We sign a contract with the customer before development starts. It's extremely rare for the customer to want changes, because with our help they correctly specify their requirements upfront.

Things actually work better this way in embedded. Agree, for pure software however.

Agile evangelists on the other hand promote concept, that 0% CAN be known or designed, so let's just figure everything out on the way.

@@piotrd.4850 nobody says that.

Yes, sorry to say that is often how waterfall looks 🙃

Sorry, but the "pencil sketch" vs "inked drawing" is not accurate. Agile is not about delivering rough/incomplete versions of work. What you're describing more closely resembles prototyping. I suspect many teams do believe agile functions this way which is why many struggle. Agile advocates delivering incrementally in ways that add value. So instead of the drawing analogy I'd maybe compare it to creating an outfit. Let's say the total outfit will consist of a hat, shirt, pair of pants, jacket and shoes. Instead of being delivered all at once, the pieces can be delivered incrementally and still provide value. Let's say you're the customer and say you need the pants and shirt the most, so my team prioritizes those two and deliver them first sprint. You want the whole outfit eventually, but you can still wear the pants and shirt without the other pieces, providing you value. The next priorities are the shoes, jacket and hat in order of value. I deliver something each sprint until you have the whole outfit. But each item delivered is complete in its own right. We don't deliver the shirt with missing buttons or just the left shoe...everything delivered is finished and provides value, it's just not the totality of the final deliverable.

@@philw3039 Your analogy is somewhat more accurate and depicts exactly what bothers me with some applications of the Agile method. Because at first, the objective was to sell a complete outfit all at once. Not hats, pants, shirts, vests separately and progressively. If you go to a tailor for a wedding suit and he tells you that first he will deliver the pants in two weeks, then the shirt two weeks later and the vest two more weeks later, that doesn’t make sense and would be worrying as to be sure if you’ll have your suit complete for the wedding’s deadline. Furthermore, in my experience of agile, that may result in amazing pants, shirt and vest but ultimately completely mismatched that you can’t wear altogether at the same time… Or a customer in a top notch shirt without pants on his wedding day. But analogies can only take you this far and will never be totally accurate. What I meant is that what I have observed is a tendency to totally forget the overall objective and product vision in favor or just making features one at a time. What I call the « what’s the feature of the week ? » attitude. Some projects and products are made for a « one feature at a time » approach, some are not. Sometimes, everything is a priority, all at once and the solution is not to split all in two weeks sub-tasks. Sometimes, all the added value you can cram into one feature is pointless unless you can actually deliver the whole complete product. Sometimes (often) your project is a marathon, not a series of sprints. The iteration process purpose is not to make amazing parts with added values, but to make sure that those parts do what they are supposed to do and fit perfectly with the other parts. Iterations are meant to make adjustments for assembling things together, not polishing each individual pieces. I’ve seen this too many times. At the start, you have a thrilling innovative concept. Then it goes through agile, features are prioritized and a first version is released to the public with only key features which all in all makes the product just « meh… ». Then you work on the next features and you realize that you can’t implement them without totally changing what you have already done and delivered… except that you can’t do it properly because it’s currently been used by your customers and you can’t mess with that now. Then as you go along, you realize that some features don’t make sense now with what have been delivered, or that users got bored waiting for the complete product and just don’t care anymore for your new neat features, or that now a competitor has released a much better product than yours that, ironically, is exactly what your initial concept was supposed to be before you smashed it into « manageable » bits. And before you know it, the whole project is cancelled like a TV series on NBC or CBS which no one will really know how that was supposed to end because they only aired 5 episodes over the 20 initially intended. But those were 5 awesome episodes, so good for you, I suppose. In my opinion, Agile method is a very good method… for prototyping, precisely. Because at its core, it just aims at delivering prototypes after prototypes with just 1+ feature every two weeks.

@@yannsalmon2988 Your point about losing vision of the product is entirely valid. This is why the Product Owner is key role in most Agile methodologies -- it's their responsibility to hold the product vision and keep the team focused on meeting the core outcomes "Delivering" is not synonymous with "releasing" in agile. The work delivered at the end of each sprint is potentially shippable in the sense that everything implemented is fully functional but the product may still be too basic to actually release to users. The stakeholders decide when the product has enough features to ship. The frustrations you listed are spot-on too, but are only exacerbated by waterfall. In fact, most of them are the primary reasons agile was formed. Teams were spending months-long requirement gathering cycles to get perfect requirements, then using those requirements for months-long dev cycle to make perfect features in order to release a "perfect" product that had everything the user could ever want on day one only to find when they released that the requirements were obsolete, most of the features weren't being used, competition had beat them to market and the product was no longer what customers wanted. Agile offers a way to get feedback early as possible & adjust to better avoid this scenario. You raised good points. Agile is not without it's drawbacks to be sure, but I think it's better suited for most software development projects because of the constant feedback and the ability for most software to be designed in modular fashion. Still, I very much understand the skepticism towards it.

“Lazy” management? More like micromanagement on steroids with unclear expectations and a lot of breathing down your neck.

Exactly, it means management can abdicate and not learn the software. They say you self-organize and I'll just count the story points.

Exactly. I am amazed how everybody is blaming waterfall but it's SCRUM which rigidly prescribes 2-week sprints

@@errrzarrr Exactly. For 'actual' development, two weeks is easily not enough, especially considering all the time wasted in "daily scrum" and associated BS..

There is not such a thing as accurate predictions. That is why they are called estimations, and not deadlines.

Unfortunately the prediction (estimate) always seems to morph into a deadline.

@@kevinmcnamee6006 nope. Usually it's fixed deadline, fluid sopce and "make it fit" like in Pentagon Wars.

Product needs to be a part of R&D. You know the date customer wants ‘something ‘ , so set a target date, and work closely with the team to build to the most valuable things first

Lol

Thank you for this. It's often debated as if software engineer is done in a vacuum, through a process piloted by an army of Kent Becks experience level developers

In all the discussions about agile and waterfall, I think your comment hits the mark closest. It's belief vs empirical evidence, assumption vs zero assumption and trial and error, something like that. The synthesis between the two is common sense, that's my experience that gets the job done. Some assumptions need to be made, some kind of frame of reference or else the project spins so far out of control it tries to solve world problems. Too much meaningless trial and error gets you nowhere either.

Exactly

Have you seen TDD in the wild? :D Otherwise, I agree.

Absolutely! The thing I wonder about is how we managed to allow ourselves, as an industry, to fall into this bucket. We don't have "Fixed cost lawyers" or "Fixed cost medical advice" or "Fixed cost shopping" or "Fixed cost business decisions", or "fixed cost marketing campaigns". I suppose we have crazy people attempting all of these things, but the reality is that lots of stuff doesn't work on the basis of being predictable. Why do so many orgs attempt to work on the basis that software is predictable, when it so clearly isn't? People have been trying, and failing, to treat it as a predictable thing since at least the 1970's, maybe it's worth trying something different by now? 🤣

Agreed: Successful: Google, Amazon, Tesla, Apple, SpaceX, Microsoft (read Rapid Development by Steve McConnell)... Failed: "TAURUS Electronic trading platform" £75m over budget before cancellation "FAA Advanced Automation System" $3-6bn over budget before cancellation "NHS Connecting for Health Project" £12bn over budget before cancellation. Lots more here: en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

This. The "agile value" of empiricism.

Nothing genuinely new is likely to succeed without iterations. There were smarter, better educated, better funded engineers trying to build an airplane, when the Wright brothers won the race. The Wright brothers were simply more methodical about incrementally building towards their goal and learning along the way. They saw that building simple gliders that flew a little were a practical necessity, and there was a lot to learn to even get that to work.

Hey, there's plenty of non-suits that doesn't understand this either. I've got multiple 45 yo senior architects at my current client who doesn't understand any of this. Every single suggestion they make is a nightmare to build and maintain long term. And they've got final say because they're architects.

​@@FudgeYeahLinusLAN Hey, I feel you. I experienced the heaven of working for an actual agile software company which turned into complete hell when we were acquired by a large waterfall company.

@@FudgeYeahLinusLAN A lot of architects reached that position for being smart and hardworking. But smart and hardworking does not always mean wise. In fact, it can mean they are very afraid of revealing that there are things they do not understand, which is the opposite of wisdom in an ambiguous situation. Many ambiguities cannot be resolved by simply waterfalling harder, and the all that bad design work becomes a sunk cost albatross.

@@ComradeOgilvy1984 - I don't think the Wright Brothers is a good analogy for software development. They had to create the field of aerodynamics while they were creating powered flight. They created the first wind tunnel. They did a lot of work on internal combustion engines getting a high power to weight ratio. They had their own engine builder. That would be like developers having to create their own language and compiler while they were creating their application.

In most places, Jira is not even configured properly.