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

--------------------------------------------------------------------------------------

🖇 LINKS:

--------------------------------------------------------------------------------------

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

-------------------------------------------------------------------------------------

👕 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!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

_____________________________________________________

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble

📖 "Continuous Delivery Pipelines" by Dave Farley

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

[ContinuousDelivery]

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

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

[mAcCoLo]

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.

[macmcleod]

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.

[vanivari]

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

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

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

[esra_erimez]

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

[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!

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

[jimhumelsine]

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

[phillewis]

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.

[hyau]

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

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

[ormundwilliams]

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

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

[THEMithrandir]

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

[tomasramirezgomez]

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.

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

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