"According to a study by PMI, 56% of projects used traditional — AKA Waterfall — methods in the past 12 months."
I found this surprising, as all the companies I've worked with have used Agile methodologies.
Perhaps I've been living in a bubble... so my question to HN is:
Do you use the Waterfall process at work? How do you find it? When would you advocate for using waterfall, and when would you avoid it?
Rarely do I see a company that iterates over a feature until they get it right (See XP). Rarely do I see a company without a roadmap and people discovering and developing a feature together at the same time.
(Shameless Plug: It's so sad that I wrote about it in "Why we always end up with waterfall" [0])
[0] https://www.amazingcto.com/why-we-always-endup-with-waterfal...
Agile makes it really difficult to get paid by milestones, and unless you have enough cash to float the entire development team's salaries until the project is finished, agile is not exactly conducive to those types of contracts.
I'm not against Agile, btw... I just get fed up with fanboys who are dogmatic about agile being the only, best way to develop software, and yet they have no real-world experience with large projects that must interact with other systems. Agile is great for when you don't know what you want to build. It's pointless when what you need to build is already well-understood and specified by contract.
The "waterfall" of today actually makes sense for large projects where you have a good idea of what the end product is going to be.
"Agile" as it's used colloquially only refers to the ability to respond quickly to unforseen circumstances, which I think is the better definition.
Have they really? Or do they do Waterfall with Jira™? I ask because I've consulted on multiple projects where they called their process Agile, because they did some things and called them by their Scrum names, or they had Scrum Masters, but with a bit of critical distance it was easy enough to see they were doing waterfall with extra steps.
When things deviate from a set of requirements, we can review and adjust the requirements accordingly so our expectations in working together can stay in line. We don't have a luxury to constantly keep changing things after releasing the software because a we work in a more regulated environment where changes will need to be reverified and validated before release, not just by ourselves, but by our customers. In the projects, we are heavily involved in ensuring a good user experience and integration testing of the software to ensure it meets our needs and solves the business problems we have.
I think it should be used when there is more than one company involved in developing an application between the companies at least, and should be avoided when exploring different design ideas and gathering requirements and scoping out the project. In any project, I strongly advocate towards doing whatever it takes to expose problems and areas of uncertainty that should be scoped out as soon as possible. It's a lot more expensive to build a solution around an existing solution than to incorporate it as part of the solution from the start.
SPICE means Software Process Improvement and Capability d-E-termination (yeah it's stoopid), but is used e.g. as ASPICE in the automotive industry and is a framework for large enterprise companies to establish policies, roles and responsibilities across their staff management tools. [1]
The SUSE article is actually a nice overview highlighting the processes and workflows and how they iterate on work products. [2]
Agile is what happens when you do waterfall but fail to actually do a proper review and assign relevant responsibilities. Its a way for software developers to feel like they're engineering, while also giving them an excuse to not do things the way their Dads' used to ..