Waterfall Over Agile In 2023???

Kent Beck talks to Dave Farley about the two popular software engineering methodologies, agile and waterfall. Is Waterfall really "back"?
This is a clip from Kent's full Engineering Room appearance, that you can watch HERE ➡️ • Kent Beck On The FIRST...
--------------------------------------------------------------------------------------
🖇 LINKS:
🔗 "TCR (Test && Commit || Revert)", Kent Beck: ➡️ • TCR test && commit || ...
🔗 "Tidy First", Kent Beck: ➡️ tidyfirst.subs...
🔗 Small Steps - "Explore, Expand, Extract", Kent Beck: ➡️ • Video
--------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE for as little as £2 ➡️ bit.ly/Continu...
-------------------------------------------------------------------------------------
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
_____________________________________________________
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here
➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd...
📖 "Test Driven Development: By Example (The Addison-Wesley Signature Series), Kent Beck" ➡️ amzn.to/2NcqgGh
📖 "Extreme Programming Explained: Embrace Change", Kent Beck ➡️ amzn.to/3K5fhg6
📖 "Implementation Patterns (Addison-Wesley Signature Series (Beck))", Kent Beck ➡️ amzn.to/3K4VWvz
📖 "Smalltalk Best Practice Patterns", Kent Beck ➡️ amzn.to/3JKyfYg
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0

[@ContinuousDelivery]

If you enjoy discussing ideas, issues, problems and even frustrations! with fellow IT guys, join us on my CD Discord via 🗣 bit.ly/ContinuousDeliveryPatreon and see lots of other membership benefits, exclusive content and competitions.

[@petergostelow]

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.

[@chpsilva]

Waterfall is not back. It never went away, it just takes 2 weeks now and uses different terms. Maybe we should rebrand it as "rapids"...

[@manishm9478]

Hahaha i love this 🥹

[@peteralund]

You Sir should be knighted

[@AndresPineros-k9t]

🤣

[@olivernjari6196]

couldn't agree more

[@stijerina2290]

😅😂 💯

[@GregMoress]

No matter what metaphor you use, they always come to my desk and say, "Just make it work!!!". So I do. That is my methodology, "Just make it work"

[@mAcCoLo666]

You cannot escape waterfall. There's no way you can just jump in and write code without a bare minimum of context and knowledge about what you're trying to contribute to. The problem is assuming all of the knowledge can be gathered in advance. So agile is really a more nimble waterfall in my opinion, where requirements are discovered and refined incrementally, and wireframes help to define what works and what not. You need the entire pipeline to be agile, that is the real challenge.

[@pureabsolute4618]

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.

[@ContinuousDelivery]

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!

[@Skibbi198]

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.

[@geelee1977]

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

[@ForgottenKnight1]

"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.

[@vanivari359]

I was at a car manufacturer in Munich for a while. Their whole organization uses an agile model where every single story (estimated between ~ 3h to 15 days) is basically a water fall with contractional and financial meaning. You promise to deliver the story in that amount of story points (principle: "you know what you are doing and nothing goes wrong, so no buffers) and you get payed for that. If it takers longer, your fault, your loss. If you are faster, good for you. That means that every story in every sprint planning is a contractual negotiation where the customer wants to reduce the price and your organization wants to increase it putting developers into the role of negotiators who have to commit to estimated hours or beg for an additional story if something unexpected happens. Also the provider puts more and more controlling into place (additional waste) to estimate better and you have "pre-sprint-review-reviews", "mid-sprint-risk-reviews"´and "pre-planning-estimation-sessions" and god knows what. because the customer monitors the delivered story points and if you are slower, you are in trouble. Because the whole thing is also a waterfall of course, planned, estimated and committed 6 month ahead of time. It is the most absurd thing i've ever seen in my 19 years in this business and all based on that idea that you can buy software like screws. I would actually prefer a classic fixed price water fall project over this "agile" model. These projects in Munich also have the highest fluctuation rates of employees i've ever seen. And this stuff enforced bad software, the amount of times developers told me that they won't clean up code or do it the right way because they don't have enough time and don't want to beg for more time. 8 month out there and i still get angry. To be fair: customer project managers can be lenient if everything is great, but as soon as they start to feel pressure for any reason, this controlling mess starts and the "a story point is 2.35 hours of work" discussions and "re-calibrations" start. At some point our devs got long lists of cross-functional roles and tasks (e.g. an "engagement manager", a scrum master etc.) they have to consider and factor in during their estimations. Absurd.

[@salvatoreshiggerino6810]

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.

[@georgehelyar]

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.

[@ContinuousDelivery]

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

[@salvatoreshiggerino6810]

@@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.

[@M0rd7ust]

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

[@macmcleod1188]

I'm retired and I preferred RUP. Based on my rusty recollection, it went something like: 1) Create a feature set contract. 2) Identify any risky (non-construction) features and develop time estimates for the non-risky features. 3) Prove the risky features/new technology will work on a trial project before starting any construction work. 4) Firm Time Boxing between 4 and 6 weeks. I preferred 5 weeks. Remove features not ready- never delay the release unless it means there are no features.. 5) No new features without renegotiating the schedule. Agile never worked from what I could see. And waterfall lead to *very* expensive failures after doing all the easy work and then discovering a risky feature was impossible. All you need for the above is A) A business analyst who understands the business and software development to create the user requirements. B) A programmer analyst to create and update the feature specs/contract C) A team of programmers and a project manager. In some cases a systems analyst and data base administrator.

[@AlignToDeliver]

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

[@jimhumelsine9187]

“Walking on water and developing software from a specification are easy if both are frozen.” - Edward V Berard

[@_Mentat]

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.

[@kevinfleischer2049]

@@_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.

[@_Mentat]

@@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.

[@archi-mendel]

@@_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.

[@archi-mendel]

@@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.

[@esra_erimez]

This video has been the story of my professional life as a developer

[@pjdominey]

I find the problem between waterfall and agile is the, very human, assumption that one-size-fits all. So I see agile (for example) trying to be applied to the coding of the fire-control computer of a tank as though there is the possibility of pushing out changes incrementally to equipment deployed to the field force. Indeed that same condition being applied to Geostationary satellite. These are not places to try to do agile. Just as IT mgmt want a one-size-fits-all language they want the same thing in development. It's just not in the real world.

[@Sergio_Loureiro]

One of the reasons people doesn't like agile is because what is taught to them as Agile. I am seeing, in different environments I've been working, people thinking that Agile is: - having a meeting in the early day on what they did the day before. - reporting how many hours they spent on some feature - trying to implement some process - having a scrum master at the end of the week asking how things are going - having a sprint window of 2 weeks - having estimations meetings - having a retrospective meeting at the end of each sprint - etc. This can be Scrum, but it is not definitely the definition of Agile, as Agile is a more generic and abstract concept. We can even say that there are other ways to do Agile which are not Scrum. The main reason people is in such a state is because the Scrum process is commercially more sellable as training courses, than Agile. Come on people, the Agile manifesto is only 12 principles and so much more quick and easy to read and understand!

[@nohandlehere55]

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.

[@phillewis3108]

The problem now is that all the “agile gurus” are selling waterfall, and calling it agile, and really, honestly believing it’s agile. And if you try to describe “real agile” (say XP) to them, they think you’re insane.

[@archi-mendel]

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

[@slipoch6635]

Yeah it's basically the SEO market for management.

[@godisB2eenus]

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...

[@ormundwilliams8065]

I remember a customer asking me "How long would it take if you don't put the bugs in?"

[@_Mentat]

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.

[@SoftwareInTheWoods]

Kent is right. The problem isn't so much in software engineering as a function, but all the hangers on in the modern day tech cargo cult trying to justify their own roles. We won't build anything without someone building 3 wireframes, someone else doing UX research to test it, someone else doing business analysis, then someone else deciding where this priority sits on some backlog. Even when it gets into the engineering team, someone will break the feature down into minuscule JIRA tickets they call stories. And all that excludes content, risk, compliance, infosec and infra reviewing everything before it goes out the door. But, you know, we're "agile" because at least we as developers don't have to write PRDs - so now our documentation is a massive mess across Confluence, Miro and Google Docs.

[@davew2040x]

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.

[@thomascking]

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.

[@_Mentat]

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.

[@istovall2624]

This guy gets it

[@errrzarrr]

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.

[@thought-provoker]

One of the main problems is holding developers accountable for building the right thing right at the right time - whereas the problem often isn't nearly so much what developers develop, but that customers (stakeholders) often can't even agree on a common goal or on the steps to reach this goal, and managers are unaware that the difficulty is aligning until the people who need the product understand what they really want, and how they want it. I've been working on an approach that focuses much more on these dynamics than on stuff like Sprints, Velocity, Planning and other things happening in development teams. We're not going to solve the real problem causing development teams to fail as long as we're not fixing the introduction point of failure, which is misaligned goals, wrong mental models - and procedural as well as organizational structures that don't permit improving on these.

[@ComradeOgilvy1984]

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.

[@FudgeYeahLinusLAN]

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

[@deanschulze3129]

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.

[@ComradeOgilvy1984]

@@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.

[@Tony-dp1rl]

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).

[@ssssssstssssssss]

I hate it that a supposed engineering field has become so overrun by demagoguery. Evaluating uncertainty, risk and complexity should be the starting point of how engineers manage the project. And then they should choose a project management model that fits the problem. Like if you are dealing with high uncertainty, especially in terms of whether the proposed solution will solve the problem, you definitely do not want to use pure "waterfall". You might want to start with throwaway prototyping until you are fairly confident in your solution.

[@closeredge5198]

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

[@piotrd.4850]

@@closeredge5198 no, that's common sense.

[@closeredge5198]

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

[@hyau512]

"Waterfall" is probably still considered a pejorative term, but I have seen it sneak in through constructs like "Quality Gates" and "Sign offs" which are demanded before a project can proceed.

[@ContinuousDelivery]

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!

[@THEMithrandir09]

Waterfall is perfectly fine... if the entire cycle takes no more than 15 minutes and you test before you implement. Then you repeat.

[@stevecarter8810]

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

[@sirgregoryadams]

After about a decade in IT and the majority of that time in software development, every attempt at following an agile approach within a larger organization that I've seen has been an unmitigated disaster. The main argument I always heard was that "it's just that nobody is doing it right", but at some point, you have to wonder... Can it even be done? Is it even compatible with how most businesses operate? I mean, nobody wants an agile payroll: "Yes, we'll either send you money every n days, but not sure how much, or exactly n amount, but not sure when."

[@piotrd.4850]

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

[@ingramdw1]

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.

[@boandersen3818]

How do you work with deadlines within agile? If you have a customer within a budget, and he wants to know if this is possible within the budget, how do you handle this? Is agile about just start and iterate until it is finished?

[@gppsoftware]

My observation is that agile approaches flourished in IT departments as a result of being accused on non-delivery and it was seen as a solution. There's a lot going for it, but it still doesn't address the fundamental fact that at the end of the day, business management/clients want to know what they are going to get, when they are going to get it and how much it is going to cost them. They are not interested in the tom-foolery of 'ceremonies' within IT departments!

[@yewknight]

The only team I worked on that managed to escape waterfall created a stripped down scrum-ban process with just a little bit of scrum but with the overarching principle that our processes and culture should only enable our team to work “well,” not necessarily “fast.” We did the math comparing how many lines of code that team managed compared to other teams per developer and our little team was managing two orders of magnitude more code (by lines) than any other team.

[@tomasramirezgomez5564]

The waterfall method never existed in the way it was mocked by the Agile Gurus. The waterfall method was always iterative, in a process where it goes from the most general concept levels to the level of detail. This has always been working in architecture, civil Igeniería and other industries that develop projects. In this way the waterfall method is not that it returns, it is never gone.

[@ContinuousDelivery]

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!

[@tomasramirezgomez5564]

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

[@npkonstan1681]

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

[@dijoxx]

Conway's Law: The structure of a system is determined by the communication patterns of the people who design it. In other words you can't change the process without changing the organizations. If you have four teams developing a compiler, you'll get a four pass compiler. Going Agile®™ in practice usually means renaming the existing structures, titles and processes. You still end up shipping the org chart. So the best you can hope for in traditional organizations is a wise technical vp or similar who has the trust and backing of the upper management to get things done, and who will recruit the right development team before granting them necessary autonomy, resources and shielding for them to organize and execute as they see fit.

[@piotrkozbial8753]

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

[@dijoxx]

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

[@DanielLiljeberg]

I dove into the agile world around 2007. I feel something has happened where we today have more companies than ever claiming to be, or wanting to be, agile and more companies than ever that got the whole thing wrong. I think there is a lack of knowledge and understanding about what agile is among the people who have the power to decide to use it so we get agile "implementations" that are teams having the different events of Scrum without understanding why they do them. Then the teams are filled with roles (instead of competencies) that all have specific areas they were hired to work with such as fronend devs, backend devs, testers, UX designer etc. It all just creates small waterfalls that we package into "sprints" that are carried out by groups of individuals who have never gotten the opportunity to understand the true foundation of agile and thus are in no position to improve according to it despite having "restrospectives". All while having "managers" who can't support because they misunderstood the whole thing from the start :)

[@archi-mendel]

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.

[@geelee1977]

"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.

[@playnvanilla5176]

It feels to me that oftentimes people in charge try to hide behind the word "agile" when they tell programmers to implements something without knowing what they want and without having thought much about it. Having iterations in the development process seems to often be used as an excuse for "I don't want to think about it now. We'll have another iteration anyway." Then, ten iterations later, they think about the concept and suddenly find out that they want features which are in absolute contradiction to what has be developed thus far. It is frustrating.

[@deanschulze3129]

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.

[@salvatoreshiggerino6810]

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.

[@salvatoreshiggerino6810]

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.

[@zakaria20062]

As business perspective , dont allow or give many chance to client to make changes during development, it go very very strict as : Requirements ? Client ok ? Sign . ui design ok ? Please sign . Testing prototype ok ? Please sign . Etc … I hate agile cause have lot of talking and micromanaging like asking stupid question how long taking you to fix bug .

[@karlgustav9960]

Agility is important and a good approach in a domain or market that is either not well researched or very volatile. If you are building the second iteration of a b2b finance suite, there is absolutely no reason to work agile, because a) there is no reason to reinvent the wheel, only to put it on a new tech stack and b) the legal requirements in combination with the financial and time constraints make it completely unnecessary to „explore the solution space“. If it’s a new concept for b2c? Sure agile is great. For a b2b suite that has competitors that have very standard feature set, there is little room for innovation and really it’s obvious what the software has to do. Sad but true 😢

[@hawhite2000]

I think the basic problem that I don't think has been solved to everyone's liking is progress tracking. People understand how to track progress in a waterfall method; they don't in agile. It's not that tracking isn't happening but is the tracking that is being done communicating that each iteration is moving you perceptively towards your final goal, or are people moving on faith that it will get done.

[@evancombs5159]

Both agile and waterfall are good, just depends on the situation of your project.

[@Delmania01]

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

[@dantobias4520]

Don't go chasing waterfalls; please stick to the rivers and the lakes that you're used to.

[@Alanblumenmkt]

The critics against waterfall Model are also apply to V-Model?

[@MatiasKiviniemi]

Waterfall never left the enterprise as investment decisions always stayed the same. It doesn't matter your outsourcing partner does sprints if you are on a fixed budget and feature promise to stakeholders.

[@dripcaraybbx]

To be fair, developers doing interface design never worked either

[@loloverland]

Agile is just an iterative collection of waterfall increments, short/small enough to reduce risk, long/big enough to create value. Design, build, test, deploy, et voilà. One can split it, name it differently, the underlying overall process is this one, whatever is the stuff you plan to get

[@AlexeyVasilyev644]

Don't need planning before you find root cause of Customer's problem . In 1st book edition Beck said "Use cheap experiments", and thinking processes of Theory of constraint provides it. And you should have good agile design and evolution road map before coding. When you have design and evolution road map then coding it just coding without thinking. Steps: 1. Find the root cause of Customer problem. 2. Describe the Goal which solve the problem and verify it. 3. Create the shortest way howto reach the Goal. (You'll get path with small and simple objectives) 4. Write (by pen on the paper) architecture solution design. 5. Think a few days about design evolution (about next steps) and write it. 6. Write code via TDD according you design. Remember: When Client/Customer ask something its Hypothesis. The root mistake of Agile -approaches - they think that Customer HAVE the Solution.But, Customer always HAVE only Hypothesis about Solution. Because Customer is not an engineer. After solving first root cause, you need verify solution, and repeat steps for next Customer request.

[@tcioaca]

Waterfall is becoming this invisible enemy that is always brought up in any critical analysis/debate discussion involving Agile. I thought Agile was all about adaptability, learning from mistakes, and being open to change. It is counter-Agile to ignore Waterfall's legacy, what made it successful (because it did have some advantages and it was not invented over night and set in stone, it too evolved and got refined). The discussion is really not very cohesive and to the point (in this video). We should not have a problem with the desire to have a predictable plan! Most of us are paid monthly! Someone needs to have a predictable cashflow to ensure our salary budget is covered! In all, we are not paid by how many story points we deliver, we are paid by how useful and business relevant our products and services really are. And, part of that is being predictable. You need to deliver features within a known timeframe, within some strategically relevant deadlines. Agile aficionados should stop painting the Software Development World in black and white. Regardless to the methodology used, deadlines and steady streams of cash are always a hard constraint for a business. And that does involve predictability and clarity.

[@AlexFirsikoff]

David, but isn't this natural trend towards waterfall just a symptom of the accounting practices and budgeting the companies do based on yearly iterations? I mean when you have a budget planned for the year, as a senior leader you would of course ask your IT folks to give you some form of a development plan for a year ahead. What do you think?

[@ContinuousDelivery]

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.

[@Koyasi78]

And here i was thinking i was crazy this entire time. Glad i'm hard headed and was taught critical thinking early in life. The process of creation is ancient and time tested.

[@buckstraw925]

It is really quite straight forward to run a longer phased roadmap for management and the rest of the company (which works for them) while the Dev Team sits underneath in an agile style software development AND they CAN fit together quite nicely. There are a few keys to make it successful. One is to recognize that a longer term roadmap is in itself agile by default given that the world is dynamic. All those people screaming for the market plan and then subsequent old school approach to product development are going to change the requirements rather quickly as time goes on. Let them and simply embrace it by updating the roadmap regularly (e.g. monthly). Do that in a collaborative style. A 2nd key to help get buy-in from Dev is to ensure that the roadmap items only list the very top requirement areas and also add a form of "commitment" (I use a padlock) which is really only set very near a major milestone level release. The business people will be ok because they "see" their big hitting items in a planning document while the Dev team can independently determine the levels of things that get built and the roadmap items themselves will only make up a part of the deliveries leaving all the agile style improvements to occur naturally in the manner that Dev would like them to occur. That way Dev will have the feeling that they are entirely working in some form of agile based development yet there will be a level of planning above that speaks to the business minded people. A "have your cake and eat it too" approach that actually works really well as long as you have a few key people in the middle of the process who understand both how Dev Team's think and also how the more business minded people view the world.

[@davetoms1]

3:32 "The fiction is so attractive that people are going to return to it." Never heard a better description of people thinking Waterfall is great.

[@danielgilleland8611]

Part of the reason Waterfall is still done by "smart people" is because in education, WE haven't moved beyond waterfall. (I speak as one of the educators at the post-secondary level, and getting change to happen is like pulling teeth.) Change happens as the speed of tenure....

[@nakaimcaddis5531]

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.

[@Flamechr]

Funny thing is that hardware works best in waterfall and software on agile because software change alot more than hardware. Most companies sells hardware and think waterfall. That is why software often struggle because they have to explain why software is alive and change all the time. Like new cyper security, AI and so on. Hardware often need to completly change its specs. And that is the beauty of software you can change the product without having to change supply change around it.

[@ashimov1970]

The army of marketers wants both food and you to feed them. That's the root cause of problems with Agile adoption

[@justintomlinson9311]

Kent talking total sense here so clearly. Thanks for this one Dave Farley.

[@hexchad765]

Unironically suggesting waterfall is something I've seen more in the last 5 years than ever

[@ZFlyingVLover]

Every product whether software or something tangible like a building needs a waterfall stage to lay the foundation or scaffolding which is the 1st %10 of the product. After that you can increase capabilities with agile. Agile w/o waterfall is the same as your manager saying "Start coding, I'll tell you what I want later"

[@ContinuousDelivery]

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.

[@adtorresitpro]

@@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

[@michaelpastore3585]

Waterfall is the best approach when nothing will ever change and everything is entirely known right from the beginning. Which is the case in exactly 0% of software projects.

[@ninocraft1]

it doesn't matter what system you use

[@_Mentat]

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.

[@mecanuktutorials6476]

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

[@piotrd.4850]

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.

[@dunga309]

@@piotrd.4850 nobody says that.

[@jixal]

I see Agile as a loop within a greater structure that Waterfall helps define. Waterfall can show how projects are to proceed and then use Agile within sections of the Waterfall to respond to unknowns or problems that pop up whilst you are in motion. Why does it always have to be one or the other.

[@neethology]

Great analogy, beautifully said.

[@arasefe]

This whole estimating and negotiating thing work against developers. First developers tend to underestimate as it is very difficult to foresee all the edge cases in a 1 hour meeting called refinement and secondly developers are awful at negotiation and when pressed against they easily lower their estimations as they want to go back to programming instead of discussing a guy who can be either a PM/PO/BA etc and who has a sole purpose of lowering the dev time. I think this agile development thing is completely working against dev as it tries to put all risk thus pressure on devs.

[@errrzarrr]

Exactly

[@edgeeffect]

I was basically taught waterfall in Computer Studies at school... and we kept trying to side step the initial stages and get the program running... our teacher used to tell us "I know your way is QUICKER and EASIER but you're 'cheating' you've got to do it the SLOW, COMPLICATED way because.... because... that way is 'correct'".

[@ContinuousDelivery]

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

[@_Mentat]

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.

[@edgeeffect]

@@_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. :)

[@_Mentat]

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

[@speedgoat7496]

I’ve worked on both Agile and waterfall projects. I found waterfall projects always more successful. Agile benefits managers and consultants. Managers get certificates and delegate all Due diligence responsibilities to developers. Consultants make money.

[@marna_li]

This is what I believe: Developers can’t escape the obstacles of plan-driven development unless they start to empower themselves and challenge the management. But most developers care just about doing programming. Leaving steering to someone else.

[@anasbiniftikhar5918]

I think Agile came into being because of constant nagging of investors and VCs asking for quicker return and time to market. Many startups and companies failed to build a working, marketable product and then Agile came. True intent of agile was to make companies deliver value often. And then this translated to Scrum method. I think systems engineering life cycle model by INCOSE is the best out there, especially the V model. In software, the V-model can be modified to micro and macro V-cycles to deliver phased/iterates product versions. Obviously it's not that easy for companies doing the hardware and software thing both but it's the way to go.

[@CallousCoder]

That is management for you. If one doesn't work try the other only to go back to the methodolgy that didn't work in the first place. But they don't assess why projects failed in the first place. And I know why, lack of pragmatism and allowing enough time experiment to find the best solution. Neither methods are a saint or a burden, you need to go about it pragmatically. I worked in film and that's truly a combination of both waterfall and agile. On set and in post production everything is agile when things don't work as planned in the waterfall stage we work around them and make sure we get the shot, or remove the shot if it's not that necessary for the story.

[@wannabedal-adx458]

I think Agile works only in small, relatively short duration software projects. Any large piece of software or something that has to be integrated with other hardware and other engineering disciplines (like UX development) you run into problems. In a large development program (especially if it is for a public sector or defense application) you need some type of program/project level planning and reporting. Also because I have seen that software developers that i work with (on a large aerospace project) do not understand where there coding fits into the bigger picture. They are farther removed from the stakeholders. Plus the intermediate step is the UX design process. I am not saying waterfall is better than Agile, just that it is a necessary evil in large programs. Agile can work within a waterfall development process though. Thanks.

[@arekxv]

Agile without plan is terrible and almost certanly leads to unmaintainable designs. Some degree of waterfall is absolutely needed in agile. You must have a general idea, general plan and general approach defined and have some idea to make things maintainable. Anything else is just terrible. Agile by itself JUST doesnt work.

[@yannsalmon2988]

As an UX/UI Designer, I never really understood all this melodrama about which method to use, waterfall, agile or whatever you call them. The problems start if you mindlessly try to stick to the letter to one of them. Some tasks need waterfall, some need agile, some may need something else that is not listed. If you want to be efficient you have to know which one to use for what, when to switch or mix them all together. Waterfall is kind of the best case scenario but it’s unrealistic so you need to be agile. But still, the aim should always be to come closer and closer to the best case scenario through agility. To make an analogy with drawing, agile is sketching with pencil, waterfall is drawing with ink. It’s almost impossible to get a good ink drawing without sketching it with pencils first. On the opposite, you rarely can leave your drawing to a pencil sketch, you have to finalize it with ink at some time. The greatest moment for me with agile is when it stops to be useful. Overdoing it with agile is in my opinion a mistake because you’re always on unstable ground with it. Or you can get stuck in a never ending redoing process that just screams « kill me now » because it’s going nowhere. There are moments where agility in a project becomes weird acrobatics and you just have to ask yourself « what were we trying to do in the first place ? ». On the other hand, sticking to the plan at all cost with waterfall will most of the time lead you into a brick wall with no way to go around it or go back, so that’s not good either. As an UX/UI designer, I often find myself stuck in the middle of those kind of things, trying to compromise between the expectations of marketing and development while trying just to deliver the best user experience possible (who’s point of view is often forgotten in those processes). In my opinion, the solution is not even in between but with a bit of both or whatever works for the project. I don’t care if it’s called waterfall, agile or whatever’s trending these days. Let’s just work the smartest way possible with all the tools we have at our disposal.

[@philw3039]

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.

[@yannsalmon2988]

@@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.

[@philw3039]

@@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.

[@java_Marcelo-xx5nw]

Thank you for share!

[@errrzarrr]

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

[@kikucio1]

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

[@dunga309]

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

[@geelee1977]

The requirements, are actually ALWAYS static. There's always an "end state", at the beginning of every project. The person stating those requirements, may not know that though. So, it takes a person, or persons, with real skills, to figure them out. Companies hate paying for skill, real skill, and ALWAYS try to replace skill, with process. Agile makes the promise, that paying for the skill of determining requirements, is no longer needed, or, les involved/important. This violates an engineering principal in place for over 2000 years, and is a fallacy.

[@michaelthompson7217]

another bikeshed discussion from my favorite bikeshed channel

[@FraggleH]

Meanwhile, the past 18 months of my life have been spent in a DO-178 project where we are constantly being sabotaged by 4 year-old requirements that made no sense even when they were written, but woe betide anyone who wants to get them straightened out. The entire philosophy appears to be making change as painful as humanly possible, even at the cost of having non-working software...

[@nohandlehere55]

God I wish we would go back to waterfall for some types of projects that aren't S/W development. The problem is some orgs are eating the dog food and use Agile Scrum for EVERYTHING. Major enterprise projects that are heavy on H/W and infrastructure are not served well with Scrum. It just becomes a bunch of whack-a-mole of a back-log of 100 epics which is just a check-list of tasks given to an underfunded/under resourced team.

[@kevinmcnamee6006]

As a product manager I don't really care which system R&D is using as long as they can tell me when the system can be delivered to a customer. From my past experience, R&D teams using an Agile methodology are often unable to accurately predict when the software can be delivered to the customer. That said, those using the waterfall methodology always have accurate predictions, but they don't always come to pass. Maybe there's a better way.

[@biomorphic]

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

[@kevinmcnamee6006]

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

[@piotrd.4850]

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

[@dont4922]

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

[@RU-qv3jl]

So true that waterfall never went away or is coming back. At the place I work they’ve gone back to introducing things like hard and fast DoR where everything must be ready before you start. Hello stage gate my old friend… We also have 3 DoDs. Dev done, testing done and release done. They must be fulfilled in that order and completed before the next stage. So dang irritating that everyone tells me we are agile too… Oh yeah, because we use scrum terminology we’re so agile…

[@henryvaneyk3769]

Agile is just a buzzword being thrown about by companies to make it seem that they are with the times, when what they actually practice is nothing at all like Agile. I have been in software engineering for 34 years, and the current hell that is called Agile and Scrum is way worse than Waterfall with proper Project Management ever was. Now, besides the endless, pointless scrum stand-ups, retros and what not, we have to make it up as we go along as the business people have no clue what they want because there is just no proper requirements analysis being done anymore.

[@Whyoakdbi]

Agile is Waterfall but with shorter iteration cycles. Basically many waterfalls jammed into your plan, so you're able to more quickly react to change or positive/negative feedback from your stakeholders.

[@piotrd.4850]

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

[@おす-qz7kp]

It is even more interesting when u try to apply agile to hardware development.

[@roddypine6077]

Never left, is just not being bashed that much,anymore.

[@CoxJul]

There aren't two software engineering methodologies - there's a whole continuum/spectrum between 'full' agile (Kent's XP?) and waterfall (SSADM anyone?). Your discussion about management and decision making structures (and cultures) are struggling to reconcile as a suitable, workable approach for a multitude of companies I deal with who claim to be working using 'The Agile Method'.

[@SubVengeance]

Waterfal is hard to achieve imo, simply because most times, people don't know what they truly want. It's often a refinement process. And indecisiveness doesn't play well with waterfall.

[@eyesopen6110]

If I had a penny for every time someone said agile was the necessary...70% of your time ends up in backlog refinement and standups.. It only benefits lazy management.

[@mecanuktutorials6476]

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

[@_Mentat]

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

[@errrzarrr]

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

[@eyesopen6110]

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

[@KyleTurpin42]

The irony is killing me that my employer has been working through a Waterfall management of Agile implementation. It's been like 3 years we've been talking about Agile, aiming for Agile, hiring for Agile, training for Agile... Still in progress.

[@ContinuousDelivery]

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

[@AlexBunardzic]

Not surprisingly, waterfall thinking is making a big comeback. Why? Well, ChatGPT is incapable of embracing change, but it's really good at executing on a Big Upfront Plan. And because the plan is to utilize it for software development, we must go back to waterfall.

[@shurnitajones8633]

Lol

[@l1belula]

oh yes, its back. Our management is all in.

[@jjadragna]

I do not think there is a good and a bad methodology but for sure there are bad application fields where Agile is pushed by ideology and it doesn’t make sense. Typically a hardware product, or a software first iteration, are domains where the team needs 12 to 18 months of development to seum good foundations need of feeling a pressure to deliver every X weeks something that seems to work. Not to mention bad application of the method, like those heavily loaded springs where management forget that bug solving and code refactoring should always have high rankings in the backlog … not just new features

[@chauchau0825]

As someone with system integrator background, I consider waterfall done right is far better than the fake agile people are doing

[@Caldaron]

0:54 a bit of a rambling going on haven't we?^^

[@thatvlad2821]

To me it looks like lack of trust between management and devs. The market for lemons. And developers contribute to this problem a lot. In many cases, no matter the style of management, devs fail to deliver good quality software. The funny thing is that a lot of practices that make agile agile are development practices and yet in many cases if someone within the team proposes doing TDD, architecture, CI etc, the first line of defence is her/his fellow developers: "no one needs it anyways", "we're not curing cancer here", "it's just CRUD app don't gold-plate it".... For whatever reason we believe that build automation==CI, that MVC,MVVM,(any geometry figure or an acronym)==architecture, that tests can be written a week after deployment and it's fine (sure, it's better than nothing), that pull requests is the only proper way of collaboration within the team... and all those believes create "common universal wisdom". And we're waiting for management to bring agile to us.

[@tldw8354]

lol. Never learned agile or waterfall or scrum. But naturaly allways did waterfall. at least for almost 15 years now.

[@mr.guydvir]

Ok, I feel that I have to do it once and for all (honestly, I'm not being facetious) - dev gurus and agile advocates, what do you guys actually mean by 'True Agile' ?!? It all always come to the same thing - we all know of that 'fake' agile, doing long, slow processes sequentially with fancy terms and rituals and calling it 'agile'.. but what do you actually mean by the 'true way of agile'? Usually the people who preach for pure, true agile are software engineers (heck, the menifesto was written by software engineers) that refer mainly to software delivery and shipping, vs problem exploration, product discovery or market exploration, and that also feels narrow and lacking to me for understanding how it plays out in real life. It feels embarrassing to admit after being in the tech industry for more than a decade, but hard as I try, I still don't get a sense of what people mean when they envision a 'pure true agile' process. No more - I want to ask some questions: Do you see agile as a delivery strategy only, or a full product life cycle process? Do you see agile as a cross company process, or r&d only? If it's the latter, and it's about giving r&d full autonomy for coming up, designing shipping and user testing the product, how does that work (both on terms of skills, workload and dev velocity)? Do you take into account involving product designers in the process? If you don't, isn't that problematic? If you do, isn't that 'waterfall'y' in some sense already? If the former is true - what does an end-to-end 'true agile' cross process looks like (in an organization with product people, designers, marketeers, legal, QA, data analyst, etc.)? What keeps it agile and non-waterfall? --- I feel like there are these 2 camps - fake agile (waterfal with rituals and habits), and pure software-engineering-fast-delivery-agile advocates. Both don't make sense to me of you are actually building a product company that should move fast and smart - doing the right thing and doing it right.

[@jlou888]

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

[@slotos]

Resurgence (well, it never went anywhere) of waterfall seems to me to be a mirror of scientific vs religious thinking. Religious thinking assumes that world is solved or at least solvable soon. Scientific thinking embraces uncertainty and goes into the unknown.

[@imqqmi]

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.

[@adambickford8720]

Have a relatively flat org, flexible deadlines/scope and empowered devs? Agile is a wonderful fit. I can also advise you on how to feed and care for your unicorn.

[@pastordnepr]

There is no such a methodology as "waterfall". Which one you're talking about? RUP or TSP or what? Iterative approach had been introduced into software dev long long before Agile.

[@aaron5877]

I do not, and never will understand sprints and the rules around “oh no don’t start a 5 point story on the last day of the sprint you’re not allowed to carry it over! You should have planned better”.

[@rrmackay]

If you want to miss your deadline is the most painful way possible go back to waterfall.

[@OSGuard9394]

The struggle is real...

[@theteacher010]

2:46 I wasn't prepared to hear Kent Beck unironically use the word "unironically".

[@davidk7212]

That thumbnail pic is giving me Hellraiser vibes.

[@23DuDe]

Hybrid Waterfall and Agile is more common than ever.

[@ContinuousDelivery]

"Common", sure, but Dumb too! Waterfall is a terribly poor fit for something as exploratory and creative as software development.

[@eyesopen6110]

"Agile" turns every 'software engineer' into a number. No direct responsibility and no recognition for success. Its all about the slow moving 'mass' and back-stabbing team members who waste endless time in peer reviews, so they can make it look like you take longer to finish your work, but meanwhile you're just involved in peer review spam by assholes (usually twenty-somethings who think they 'know it all', yet its their first or second job..)

[@brownhorsesoftware3605]

The suits will never understand that software development is a recursive process. Why would managers support their own elimination?

[@ComradeOgilvy1984]

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.

[@FudgeYeahLinusLAN]

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.

[@brownhorsesoftware3605]

​@@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.

[@ComradeOgilvy1984]

@@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.

[@deanschulze3129]

@@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.

[@pandastory-abookseriesabou8568]

👋🏻​ Like it! ​🎯

[@rustythoughts]

I think fixed cost outsourcing and insourcing models make people think that they can’t start until they know how the work will end. After all how else could fix the costs? And lots of organisations really want fixed cost outsourcing to work. Once you buy into that fixed cost assumption a fixed scope follows hot on its heels and waterfall follows intuitively. Such assumptions and intuitions have to discount what will be learned through implementation, particularly when handling the complexities of implementations are what need to be understood. Intuition can be a really bad guide to handling complex problems that require learning and discovering to solve.

[@ContinuousDelivery]

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? 🤣

[@pandastory-abookseriesabou8568]

​👌🏻​ Agreed 🚀​

[@JaumeSabater]

Chnage needs to come from the top. If the directors dont buy it, there's little to be done.

[@OPMDK]

It’s because all these special VERY important people now have money and power and since waterfall goes with traditional business practices of those with money and power #silconred

[@slipoch6635]

Sorry but a bit of your video is a bit misleading, waterfall examples where there was large-scale successful impact: Windows MYOB UNIX Deluxepaint And so many more. I hate waterfall perosnally, and tbh 90% of businesses that claim they are agile are actually waterfall. Agile is great, but waterfall can and does work, it's more of a pain in the arse when things change after the beginning of the project, it;s slower to market, and keeping it updated after launch is a pain (usually), but saying nothing has ever been successful on waterfall is a fallacy.

[@errrzarrr]

Exactly

[@marcinrutkowski9075]

When I see AGILE and JIRA mentioned in the same job posting, I immediately know the job will be extremely frustrating and should be avoided. JIRA is a tell that the methodology is waterfall, development time and phases are set up front, and developers are accountable to meet the waterfall stages (but you also waste time for a morning standup and weekly progress reviews). By the time the project reaches production, its poorly architected, holding together by a bunch of hacks and likely became a rigid singleton to make it pass the deliverable requirements at the deadline.

[@piotrd.4850]

In most places, Jira is not even configured properly.

[@Larsbor]

Weird title .. it seems `old´ people dont understand agile, or do Jack Welsh inspired fake Agile.