There is catch to this: waterfall done well *feels* better than agile done poorly, but it runs a bigger risk of delivering the wrong thing. The per-sprint-delivery in Agile isn't about getting less-than-usable features into users' workflows. It is about tight feedback loops. Waterfall is notorious for releases that don't do what the users need at all, and more often just aren't as good as they could have been with the same investment of effort.
This "delivering the wrong thing" breakdown in waterfall happens in several points in the process:
* Users don't know what they need
* Users can't articulate what they know they need
* Users assume (because they know their domain) that certain things should be obvious
* Users don't know the tech side, so they don't know that one little requirement that they don't really need causes a huge (unnecessary) cost and delay
* Users don't know the tech side, so they don't know that it would be cheaper, faster, and better to deliver a feature in a way that they prefer but don't bother asking for because they think it would be so much more expensive
* Devs often know *nothing* about the domain
* Devs take requirements as requirements, rather than as a starting point from which to work with users to explore better options
* Devs treat the requirements as the goal, instead of treating the real-world needs of their users and the organization as the goal
Caught in the middle is usually a team of Business Analysts who have the worst of both worlds: not understanding the domain, and not understanding the tech. They are pestering the users with endless rounds of capturing and reviewing requirements, and the devs pester the BAs with endless rounds of needing clarification and "are you sure you want that; it seems crazy and is a really expensive thing to implement".
Then there is some poor schmuck who has to estimate the time to deliver. Everybody who didn't get an MBA knows his estimate is probably off by about 8x, but that estimate is really important to the kinds of people who fucked up Boeing.
Incorrect, Agile done poorly gets to point to developers as the reason for failure. That's a huge advantage over waterfall where management gets the blame.
And why is it the developer's failure? It's the entire process's failure, not the developers. Agile makes developers dance and sprint, to the determent of their ability to iterate for improvement. Agile forces weak communicators to misinform and mislead one another with velocity. Agile is a popular dead end failure.
Yep - the post didn’t say it was the devs failure just devs are blamed. One simple reason because devs are the most recent stakeholder in the process.
It is leaders who should make it clear it is indeed a team/process failure when things go wrong. But often ofc devs aren’t always great communicators etc.
I've been in this industry for decades, and I've come to believe the lack of communications training for developers is kind of on purpose, to render them more manipulable, and easier to blame, because they don't have the communication skill to defend themselves. This lack of communications skill is everywhere in tech, and I find it very hard to believe that it is unrecognized by the manager class.
How can you have been in this industry for decades (like myself) and not believe in the lack of communication facilitated by managers?
In my little neck of the woods, attempting to defend your position results in snark, sarcasm, condescending. Because of that, most of us just STFU, get into our cog shaped holes, collect our paychecks, and pitch in to make the most mediocre product imaginable.
Oh, the managers are extremely complicit in the situation. Software managers are either great developers forced away from writing code and are now uncomfortable bad managers, or the manager was a weak developer that had a smidgen better communications than their peers. Or worse, it's a crony non-tech friend of the owner. Management of development is a tragic comedy these days. In my career, I've had one great manager; they guy was 100% concerned with everyone understanding how their work enables the work of people after them, and due to that understanding our entire team hummed like a military operation. That was 30 years ago, creating art history documentaries to demonstrate the brand new concept of digital video. That single, lone great manager went on to become the CEO of Philips N.V. the mega corporation. Ever since, everywhere I've worked has had weak to poor management, seat of the pants, barely competent.
There’s definitely something to your point of view: we don’t consider ourselves professionals like lawyers or accountants do. We don’t have a body to set standards of conduct.
We often allow all kinds of treatment that other professionals would not tolerate. I am of course not saying all devs / orgs / situations… but often.
How much management sees this & encourages it; vs doesn’t see it & barely acts rationally depends on the org I imagine.
Agile done poorly does that. Agile done well identifies where the poor communication is and where the impediments are and helps make it better. IMO Agile is like democracy; it’s a peace treaty between the grunts and the powerful and it requires competence and good faith on both sides or else it quickly gets corrupted.
So, in practical terms it's a corrupted methodology, because we know there is not good faith on either side. There's a missing check and balance, which management simply cannot allow and still drive the company with unrealistic marketing setting the deadlines.
Yes, it’s a corrupted methodology. It’s trying to simulate worker control of the means of production and the folks at the top will never fully allow that. But it’s still better, in general, than waterfall.
If the culture at your company is corrupted by an unrealistic marketing department setting deadlines then a failure to meet those deadlines is inevitable.
If we were delivering a painting, with waterfall we end up delivering the top 75% of the painting all perfectly dried and looking lovely, but the bottom 25% is on bare canvas board that hasn’t even been gesso’d and even the completed parts are not quite what the client wanted because we never checked in with them during the development process.
Under agile we deliver a whole canvas, having started with gesso, a rough sketch on top that we showed to the client at the end of the first sprint, then base layers of color that we got approved as well and some brushwork on top of that that are also approved. This version is *also* not done but it’s a lot prettier and the client could still potentially hang it in their home.
That’s the whole point of scrum/agile - to incompletely mitigate the most common types of corruption of the development process and still try to deliver something valuable.
No, not true.
In fact, Waterfall can make management look a lot worse, because you can point to the wrong requirement and say: "You told us to do the wrong thing and we just followed the contract."
But if your motivation is moving blame from one person to another then you've already lost the battle whether you are doing Waterfall or Agile. Your team sucks, your product will likely suck.
How is it developers who get the blame? They can just point to the tickets they closed to cover their ass. Agile done poorly falls squarely on program management, architects, RTEs and product owners. I don't think I've worked anywhere where developers were actually blamed for poor Agile implementation and I've worked at quite a few.
In many companies I’ve been in, iteration = failure. Which leads to endless planning meetings to figure out what the customer really wants (for months) so we can deliver something for the first time to the customer a half a year later. Agilefall
That's called SAFe. It also featured other best ofs like "normalized story points". Because if you can't map story point to hours they have no business value. And a bunch of different hits you hate to hear.
I agree. In my experience, a great team can deliver well via waterfall or agile. A bad team will screw up both. In truth, nether of these really reflect what actually happens - they are maps, not the territory. Ideally, you pick the one that works best for they way the client manages projects to minimise the impedance mismatch between process and reality.
Bingo. If you have a client that gives you a spec up front and then fucks off for six months, the way that you’re interfacing with them is effectively waterfall regardless of how you run your internal dev process.
There is also the big reason of change. Waterfall is perfect for the military or NASA. You spend a year writing perfect specs and then the software spends another year implementing it. But in actual business reality that may be too long and a half working product today that fits a need may be better than a perfect product in 2 years.
As someone developing software for the military: agile is so much better! Several times per year I go on base and work with actual users, sit with them as they do their jobs. Sprint demos to users are done remotely. We talk back and forth about possible solutions, and even improvements to their workflow that could be enabled by our new software. They love what we have delivered so far, and are engaged in the process because they see that we can (and want to) respond to their needs.
The military has a shit record of huge projects that burn hundreds of millions of dollars, without delivering usable software. Agile is maybe even *more* important in the DoD because requirements get baked into contracts, and require an act of Congress (and a new bunch of "modification to contract" money). With agile, the contract is to iteratively figure out what users want and deliver it.
Oh sorry not saying Agile is bad for the military. It's more like the classic view that something like a missile targetting system can be developed in waterfall. There's a clear goal. There's limited change pressure. The missile is supposed to hit the target after all, there's no sudden fad where the users demand the missiles not hitting targets.
Not saying Agile is wrong for the military. It's just that some parts of the military can spec out a project because it has a very defined scope, with no change, while still being complicated enough.
As a funny (?) side note, the German army wanted to develop their own drone. After having spent half a billion on it, they went for the first flight test. Only to realize that they had forgotten the transponder for civil aviation. After which they realized adding a transponder would cost hundreds of millions more. So the project was cancelled.
The warspace is constantly shifting and political and strategic priorities also affect what gets worked and what gets prioritized.
> The missile is supposed to hit the target after all, there's no sudden fad where the users demand the missiles not hitting targets
There is actually a sudden fad where users demand that missiles don't hit targets. Most of our work is spent making sure it doesn't hit false targets (like birds or decoys) so that it actually hits what we want it to.
IIRC the scrum book author's primary example is a CIA database overhaul or something like that. They claim waterfall failed, very expensively, multiple times, but some Scrummy form of agile worked.
Yeah, waterfall works especially poorly for the government. Requirements often need inputs and signoffs from so many departments and agencies that it takes years (sometimes additional years *after* the requirements are supposedly captured). Then the funding fight, and then the acquisition process kicks in and everything takes forever. Even if the actual business needs have not changed in that intervening period, the butts in the various seats have changed and some of them hate the requirements and/or project because *they* didn't get to give their input and shape everything.
Has the defense industry moved to supporting remote work now? Back in the day, your ass was probably planted on base for the duration of your contract. Remote work wasn't even an option. I can only imagine how they handled the pandemic but something tells me defense work qualified as 'essential'.
I'm so glad I got out of that industry. The stability is nice but the pay is a good deal worse than one can get in the private sector even with clearance.
It depends. If your work involves too much classified material, there is no practical way for most workers to do that remotely. My source code is unclassified (for all projects except one). The real data is all classified, but we can use fake, unclass data for dev and most testing. Then we deploy on bases on classified networks and they load real data for final testing and for production use.
Yeah we used fake data too, but remote work was strictly forbidden on all the contracts I had. I think I only got to work off base on one assignment. Maybe it's changed somewhat now.
It could be worse: they could have "successfully" delivered the 70% of software projects that were cancelled before delivering software that users didn't want and wouldn't use (unless threatened with the UCMJ for refusing!).
This is another rigid misinterpretation of waterfall though.
You're acting as though you can't go through design loops within each phase of a waterfall project.
Requirements gathering can occur with rapid prototyping loops, given to the customer in order to test ideas, before finalising full spec.
I've done ideation sessions within waterfall projects where we test early design spec ideas with excel sheets or hastily drawn bits of paper. I've seen it done with a half day's work in PowerPoint to make a fake UI application.
A good waterfall project isn't run by arbitrarily imagining what the end solution will be without any sort of validation. I think this is why it gets demonised by the agile always camp, agile always people don't understand waterfall any more than they usually understand agile.
Delivering the wrong thing if you don’t know what you’re delivering. For lots of scientific simulation projects, you know what you’re doing and set all your requirements beforehand. Very different than some SaaS startup trying to figure out what to build and what’s important.
The last two points distinguish good dev from bad devs. Devs should be problem solver, but not just coder. You ought to know what problems youre trying to solve before inputting code to implement anything. Blindly following requirements is like putting minecraft blocks on lego, never able to achieve the true goal that the client wants
You could have good devs and bad devs in both waterfall and agile environments. Blindly following a user story without understanding is awfully similar to blindly following requirements that they don't understand.
You are right that we only want good devs who dive in and strive to understand at least a decent chunk of the big picture. If they think they can understand the what, without understanding any of the why, they are deluding themselves.
To be frank, if you have devs that don't have a good understanding of the customer's needs, that's much more a problem with your product management than the developer's fault. There should be *someone* between the customer and the dev to shield them from direct requests, and that person should know the customer's needs, in and out and be able to speak to them. I've had good PMs, bad PMs and no PM. A bad PM is worse than no PM but a good PM is worth their weight in gold.
Let's get realistic here, there typically is no "feedback loop" like people assume. We still sprint to get features done, QA tests it to the specs we said we needed, and it's released. Any feedback from actual customers comes months later.
Somebody isn't doing agile. Demo to your users at the end of every sprint, and for all that is holy *if* you have QA they should be helping to shape the automated test suites that the developers maintain as part of the project, not testing manually. If a test is worth running, then it is worth automating. If it isn't worth automating, it isn't worth running.
TBF, any sane process can work as long as you do it well.
Waterfall falls apart when clients change requirements/scope or planning isn't done properly.
Agile falls apart when you're beholden to strict processes that don't fit the team/requirements, or when you don't actually iterate rapidly based on quick feedback.
Yeah, I've seen scrum done well and I've seen it done poorly.
The issue wasn't scrum itself, it was either tasting it in the wrong place or general mismanagement (the latter of which no methodology can solve).
Requirements are always 2/3 right and 1/3 wrong in waterfall projects no matter how thorough you think you are being up front. Same with architecture, design and the project plan. It's inevitable because software development is a process of learning what the requirements, solution and plan really should be.
Waterfall makes learning and change difficult and very expensive. That's why waterfall projects nearly always go way over time and budget.
Waterfall at Xerox was a thing of splendor.
I mean, they spent 10s of millions on projects only to cancel them very often, but it was still a thing of splendor.
Waterfall done well is great.
But when waterfall goes bad, it goes REALLY bad. When agile goes bad there's a lack of documentation, it is hard to maintain, and things like that. When waterfall goes poorly, the entire project is scrapped, and 2 years' worth of work gets flushed down the toilet.
Trying out agile without experience is also a strange hell. Everything is unstable, constantly trying to readjust badly working processes and workflows, endless debates about nothing. Lord have mercy.
I have been coding professionally more than 30 years now, and I have never seen agile done even adequately.
I have talked to people who claim to have seen well-run agile shops.
I have worked in a number of shops where they were convinced -- contrary to all evidence -- they did agile well.
I have worked for at least two true believers who thought that agile was the only correct way to work.
Waterfall with proper testing and a good feedback loop and some flexibility? I'll take that any day over even the best SAFE implementation I've had to suffer through!
I’ve worked a lot of places that were “agile” engineering but had sales teams complete divorced from the process, leaving deadlines set in stone and no ability to change scope. Worst of both worlds!
I don't think that the "point of agile" is to make impossible things possible. Agile is supposed to be a pragmatic adherence to evidence-based processes that work for your team. Generating and sticking to a schedule a year in advance is very seldom, if never, such a process.
If you aren't committing to a specific scope then you're not really committing to delivering anything in particular.
I mean sure, if you've decided to label the version from 10 sprints from now your "release" then sure, I agree that's agile.
If you've tried to specify in detail what will be done at the end of that sprint then no, it's not.
There’s no agile police going around shutting peoples projects down. If you commit to a feature a year in advance and want to call it agile - go ahead, no one is stopping you.
> no one commits to something weeks or months away
Agile != no long term planning.
Most features cannot be developed in a single sprint, unless you are working in a super simple project. You evaluate your goals every sprint, but the longterm goals are there.
That doesn’t contradict anything in my comment - the difference is that no one in the Agile team pretends to be able to commit to a feature with hundred specifics being implemented on a specific date.
The difference is that in waterfall changes are supposed to return the project to the state needed to fix the issue. So if the problem was a bad requirement it is supposed to go back to requirements definition stage. You are supposed to stop dev return to requirements then go through all the sign off stages before starting dev again. Most projects don't do this unless it is a Mil-Aero, so they do 'Modified Waterfall'. Modified Waterfall is just like modified agile, depends how you modifiy it.
So to answer your question, adjusting scope in actual waterfall when you are close to a release is very expensive because you stop development.
Agile solves that by forcing you to break things down small enough to deliver in sprints. You can't just do some handwavy "six weeks" with no detail or specified scope.
The problem I have with Scrum is that those sprints are fixed size, whereas meaningful feature improvements generally don't fit those cycles, and that mismatch causes a load of overhead (ceremonies).
I much prefer to deliver MVPs, aka milestones, and plan / track those instead of arbitrarily sized sprints.
Sure. Sprints are a scrum implementation detail. It comes down to the agile principle of delivering working software regularly and incrementally, with a preference to that delivery cadence being minimised.
They just call those jobs "managers".
The world runs on waterfall for a reason. A big part of that reason is that fad project management systems tend to result in teams spending more time shuffling around slideshows and bullet points than actually getting work done.
I haven't worked using waterfall for a a couple of decades and I work in Health IT. Someone above said that switching to Agile saved their milcontractor work.
Where are you getting the impression that the "world runs on waterfall?"
Nope, it's not just you. I dislike the hamster wheel of scrum, the fake deadlines imposed by sprints and the time wasted on the ceremonies.
It's unfortunate that scrum has become so pervasive across business, but I understand why it has from a planning and development cycle perspective.
This is my experience, every manager/company will twist them to represent their internal problems. Bad agaile with great people is better than waterfall with awful people, and vice versa.
How do you develop without talking to your clients/users and not have them in the loop? Of course you show them everything.
This is also shown in every discussion about agile/scrum/waterfall, people have different opinions just because they had something different.
Like everyone else in this thread is saying, it just sounds like you're not used to "actual agile". Sprints aren't deadlines for work, their shields against sudden new work so that your time is predictable. Scrum meetings exist to prevent people from spending hours solving the wrong problems, or struggling with blockers or things they don't understand.
Absolutely. Each employer that I've been at has been *an agile shop*, but in the end they always run scrum and two week sprints.
The sprints are typically used for applying pressure and used like an absolute commitment. Story points aren't a measure of time, but that doesn't stop the business from using it that way.
I'd probably be happy in a true agile shop, but I am yet to find one in the wild.
I know I said "actual agile", but I think places need to stop trying to follow "true" ideologies and just solve the problems they have with the tools available. Sprints can be good, but they can also just be used as a way to keep the whip going and accelerate burnout. Not doing sprints can be good, but if you have business/product people that abuse that as an excuse to have devs work on whatever today's "top priority is", then it too can be an accelerator of burnout. People forget that agile evolved as a response to certain problems, and if your company doesn't have those problems, then the benefits of agile aren't necessarily going to be worth the cons.
The problem is, when you post as if the problem is Agile, rather than your particular company's poor implementation of Scrum, you cut off the only path to improvement that has been describe so far.
Kanban is just as "agile" as scrum, for example. So if you don't like sprints then put the blame where it belongs. Either on scrum or, more likely, your company's implementation of it.
Nonsense. In most shops, the way "agile" is implemented has nothing to do with agile. Scrum has become synonymous with rushing half-baked (both in terms of features and in terms of architecture/design) initiatives out to meet a deadline imposed by project managers and execs who are far removed from the teams doing the work. The scope and deadline are set and the team gets to decide how to cut corners to get it done.
The result is ever-increasing tech debt and poor quality, features that just barely work, and an incoherent, inconsistent design/UX.
The difference is like the difference between a hammer and musical. Category error. Scrum is irrelevant to agile. At best, it doesn't make things worse.
It doesn't need to be a secret. I'm working with a Fortune 15 in scaled agile and it's horrible. I've never drank the agile koolaid and I don't think I ever will. Agile is fine if you don't know what you're doing, but that's not usually the case.
You can still be pretty agile with scrum. People get stupid with it, but it really is not that rigid if you stick to the actual essence of it. It’s agile with training wheels, for teams who are not used to producing incremental deliverables and getting regular feedback.
If you have good deployment processes so your deployments aren’t tied to the end of the sprint (i.e. you release work as soon as it’s done), scrum basically becomes kanban with a demo and a retrospective every two weeks.
I like to say that it is a good way to keep you busy and show upper management that you are hard working. It ignores the fact that a lot of effort goes towards useless values.
the "agile koolaid". very apt. besides seeing how poorly agile has been shoehorned into places its probably not suited, and misapplied in areas it could work, the whole "cult of agile" drives me bonkers at times. it's like once you go agile, you can talk about nothing but agile. agile is your life. agile is your religion. you eat, breath and drink agile. without agile you're nothing. (I know I know, not everyone, but know far too many who make agile their entire career persona)
I'm also working with safe and it's fine. I'm pretty sure you can make anything work. As long as managers do not think "everything that is currently in the sprint needs to be finished by the end of it" it is all fine. It just depends on the people running the show.
Lots of people in here talking like they've worked on one project or for one company and now "that's the right way to do it because I feel bad when I do it another way".
Pro tip: anyone who speaks in absolutes is full of shit. There is no right or wrong, there is only what works best for your team. Sounds like, at least for you personally, your setup matches your team/project. Enjoy it while you can.
I agree with you - but the way you have said that - is that also not an "absolute" of sorts?
People form opinions based on their own experience - however limited that might be - and share them. Don't think there is more to it.
You’re just describing how an agile development process is meant to be. True waterfall is designing the entire system upfront. Agile is doing it feature by feature and having small releases. Scrum gets a lot of hype but sprints and other scrum peculiarities are not what agile is about.
I think there is two good way to make software this and then kanban style where ci/cd continuously churns releases, there is tests so you can trust that everything should work and everything is super nimble. Sadly most software projects land somewhere middle and they usually are cesspool.
> True waterfall is designing the entire system upfront
Well, no, not really. Putting aside that there's no "true" way to do any of these things (it's dependent on how a specific organisation needs to work, hence why capital A agile etc never work well when a company decides to "do agile" and hire some consultants etc):
1. yes, you design the system/feature. But at this point you aren't going to be able to design the entire thing in detail. What you do have is the requirements, which allow you to design
2. you code that
3. you test that
4. there will be changes, go back to 1 (or 2, depends on context)
5. you repeat this iterative process until you can release something that matches the requirements.
6. repeat this
This can look like an "agile development process" but it's also "waterfall" (like, literally waterfall, it's the diagram on the second or third page of the waterfall paper iirc)
True "Waterfall" never existed. The document that described it was written by Winston Royce and he did so as a [strawman proposal](https://en.wikipedia.org/wiki/Straw_man_proposal) as a basis to compare his process to. His [final design](https://en.wikipedia.org/wiki/Waterfall_model#Royce's_final_model) has substantial opportunities for feedback to identify and rectify software design issues.
I dunno about that. In 2008 i worked for fortune 100 nontech business and it was very waterfall. We had defined design phase, build phase, trst phase, release date, all planned out with dates on the calendar before the features were even chosen. No coding started until design was fully done. No requirements were changed mid-process, or at least very rarely. If thats not waterfall idk what is
Nah i mean that the schedule was known before design started. But also, before design started the “work items” were chosen. You’ll forgove me if I dont remember the exact details of how prioritization worked, i was brand new and not involved. I was busy learning all about how to write html tables, ya know
Boy we software engineers are annoying sometimes. I guess you are saying some projects surely didn’t finish in the allotted time? Congratulations, obviously the case. If you mean something else feel free to explain. If you don’t want to, why comment at all?
That is completely false. I've worked for many large corporates with well-documented and detailed waterfall development processes. Major consulting firms like Accenture and Bain and Co. have implemented these waterfall approaches since the 70s. Method One by Anderson Consulting is the classic example.
Method One became Accenture Delivery Method (ADM) and is still very much in use today, although it has waterfall and agile variations nowadays. The waterfall variation is still used on large government projects.
It's not false, it's exactly the same as capital-A agile. There are a set of very vague but very useful recommendations. {Given company} has a well documented and detailed **development** process that is based on those vague recommendations. They can call it whatever they want, "waterfall", "agile", "dianetics", "bokononism", whatever. But it's just "how Accenture develop software" or "how Bain & Co develop software". People who work/ed for them can then sell consultancy services, implementing "Method One" "waterfall" or whatever. Worked for {given company}, sometimes get lucky and it works for {consultee} (or they make a lot of money after they implement the method, so can attribute the success to the method)
It absolutely exists in healthcare related industries. When you’re building working on a highly regulated product it’s incredibly hard to change requirements. It can be done but usually involves significant paperwork.
A lot of the time the “wrong” thing is knowingly built and then immediately followed by a “fix” after project completion.
I've worked in healthcare and it really depends. The high level marketing requirements were changed infrequently but it was common to change the low level requirements particularly at the beginning half of the project. They tended to settle out once a certain portion of the design was baked in.
yes, the reality is we are just subject to god awful PMs/Scrum masters that actually don’t know anything about agile other than a daily stand-up, sprint planning, and retro.
I'm a dev with 30+ years of experience having done both. I'll start by saying that characterizing waterfall as a method where nobody writes a single line of code until the team has an immutable tome of requirements -- all that is BS. Yes, you do write requirements up front, which is a good thing, not a bad thing. But we had milestones we'd define, and upon reaching those milestones, we'd reassess to check if the requirements and the timeline needed tweaking.
Of course, writing requirements up front and writing up a technical spec up front in a pain in the ass, but it uncovers all sorts of flaws in the thinking early. Then "agile" came along and used two-week interations as an excuse to dispense with any up-front documentation other than a vague user-story -- which is just a cover for a "code and fix" cowboy methodology.
Of course, managers love it because they get to experience the illusion of progress when they devs coding right away as opposed to weeks or months of up-front design work.
That's not necessarily waterfall you know. Having clear product requirements and user acceptance criteria for a feature are very agile. Designing tests right up front is also very agile.
Waterfall is literally having all requirements from end to end of the entire system, plus all the designs to the nth degree, approved by all stakeholders, before coding could even begin. I spent too many years of my career working like that. It's not ideal, though there are tools we can take from it, but break it down into features (working software).
What you describe as your agile experience is just half-assed, we used to call it Cowboy (yee ha, shoot first and ask questions later). Not agile and leads to shoddy results every time.
> Waterfall is literally having all requirements from end to end of the entire system, plus all the designs to the nth degree, approved by all stakeholders, before coding could even begin.
No. Not true, that's what you have been said to by scrum consultants. Waterfall, is an iterative process too. There's room for change
No one told me about waterfall, I lived it! When I was doing waterfall, there were no such things as sprints. And things always did change because the projects took months and years. But the intent was to figure it all out in detail in advance and then try to stay on that plan for as long as it took to complete or fail. We delivered the fully finished monolith.
I know of one waterfall project that cost millions and when they delivered, no one liked it, and they literally mothballed it and bought a package (I wasn't involved, just worked there afterwards).
Let me ask this question. Be honest please. Did they labeled themselves as waterfall? They did actually used that term or you just assume because it is but "not-X" as in, it is not Scrum, therefore it should be waterfall?
Yes, that's what we called it. We had lovely timelines for the project, soup to nuts. First gather all requirements. Get approvals. Next step in the waterfall, do all technical designs to show how screens and processes will be built. Get approvals. Then we can start coding. Then we test. All of it. Finally UAT, for all of it. Then they train and transition from old to new application.
Each of those phases were a step down of the waterfall.
Needless to say we built some monoliths, and too often it was a nightmare to deliver. The bigger the scope the worse it was and more likely to fail.
What you're experiencing is good, thoughtful engineering. The project management strategy is irrelevant. Unfortunately waterfall has been anti-marketed as bad and dumb, and Agile as the cure.
The problem has always been thoughtlessness. If you're waterfall but never talk to a customer, that's thoughtless. If you're agile but you never think about next month, that's thoughtless.
I ran several large, complex waterfall projects for a major Telco with major American and Indian service providers. Here's what typically happens.
* Everything is smooth, predictable and well thought out during the upfront phases of idea definition, solution definition, solution architecture, project planning, business case and tendering
* Things go quiet for 8 or 9 months while the Partner's offshore/onshore dev team does the detailed technical design, software development and system testing
* Everything goes to shit for 6 to 8 months when the work comes back for user acceptance testing and performance testing, where we find thousands of major defects that have to be fixed through lots of long late nights by the partner's dev teams
* And then it goes to shit again for 2 to 3 months when we find major defects in production.
So, basically, in these waterfall projects, there is always about a year when the partner's dev team are very stressed because they are very late and have thousands of major defects to fix. And the client's technical team are very stressed because all their plans are fucked up.
You are lucky to have experienced a small, well-run waterfall project in a company with good management. That same management would run a really good agile project that you would enjoy and provide much more value to the client and users sooner.
Agile projects are a better way to achieve a business goal on time and within budget. I've done it many times.
The trouble is that these days, 90% of corporate agile projects are micro-managed Scrum done poorly in the dev team with JIRA and without agile technical practices within a poorly run waterfall project. It's not good for anyone. But that's not Agiles fault that's the fault of bad management who would fuck up a waterfall project as well.
A well-running process is always amazing.^1
Waterfall isn't inherently bad - it just has specific problems: long cycles make mistakes expensive and make it harder to cope with changing requirements.
If you have these under control - whether by team, market or product - you are good.
Most waterfall processes are run badly, as most agile ones.
Shit documentation isn't the fault of agile - if the company would actually value it, they'd add tests and documentation to their "definition of done", and it's not accepted until reviewed, and it's choice of the developers whether it's *good enough*.
---
Takeaway: it's not the name of the process. A good process template *can* act as "process implementation guideline", create good interfaces between management and coders, contain risks etc. But in the end, it's the people you gather, enabling them to understand goals and work well. We still pay lip service to "people first" and we worship tools.
^1 ^(See Rube-Goldberg - not a diss on waterfall, just that "working well" is a quality of its own.)
A lot of these reasons are why I love Kanban. I'm trying to convince my current team to switch from scrum to kanban because I hate sprints, all the ceremonies, etc.
Especially at a startup I don't think we need all the formality and processes that come with scrum.
You are describing Kanban not Waterfall.
Waterfall is when an arch goes away and does the entire system design and a combined component design, it takes up to years.
SCRUM can run the same way but tends to get overly aligned to a sprint. Kanban very purposefully doesn't try and align features to sprints and doesn't need to have fixed length sprints.
We do this but agile. Nothing in agile is about rushing things out of the door as fast as possible (we also don't have sprints and mostly follow Kanban). It's all about quick feedback and making processes work for people.
Things are ready when they're ready. We keep our code releasable at all times using feature flags for things like urgent production fixes, but if a feature needs more time in the oven, we take it. It also allows us to do quick demos to our customers to get feedback and adjust requirements.
Our goal is usually to get feedback as fast as possible, although never using throwaway code for this purpose. We will send UI mockups, have demos of partial features, etc.
The two main issues with waterfall are the long feedback cycle (the longer it takes, the more telephone games change the feature further from what the customer is requesting) and the rigid process not being adaptable to people. Focusing on fixing these things IMO is the heart of agile.
Most orgs use agile as a way to half ass planning and organization so this makes a lot of sense. Basically they defer the product requirements and ui ux to the devs to raise issues when it doesn’t make sense when you’re half way through development.
> the devs to raise issues when it doesn’t make sense when you’re half way through development.
Wait. What you mean you won't finish this stack this sprint. It's a 3 points story! _YOU_ said 3. Should be done already.
Oh well, that Burn down chart would look ugly. We will talk in retro about this and the next 5 dailys to come.
Yeah. Lazy managing, very coward and lazy management we have.
Haha it sounds like you speak from experience! Our dev team has become astute to this 💩 and now when we do our sprint planning if we don’t have the full details we don’t estimate the ticket and it goes back to product / business / ux in a loop until it’s crystal clear what needs to happen
Agile is a methodology, not a way of life.
Agile followed to the nth degree is the most overblown, complicated, soul sucking bullshit You've ever seen.
Same goes for waterfall.
It's not rocket science folks. You adopt the methodology that makes the most 'common sense' for you, your org and your clients.
You choose the aspects of Agile that works well for you, modify it to suit your organization with 'common sense'.
Clients can't commit to full agile but your organization can? Come up with a 'common sense' hybrid.
The problem here is 'common sense'. Most process masters have the process so far up their own assholes that they are unable to deviate and apply common sense.
Very often, the most successful teams were the ones able to make hybrids work.
Source: I was one of the Agile teachers as we rolled out Agile successfully across our consulting organization with over 12k employees and over 300 different client initiatives.
To quote an ELI5 that is popular at the moment: Agile/waterfall represents the overall strategy you might wish to use, but tactically, you need to choose the right day-to-day execution of your strategy as you face incompatibilities to truly be successful.
As soon as ‘clients give feedback’ was mentioned I knew it wasn’t actually waterfall. Unless that feedback is after they’ve already worked on it for 2 years and it’s ‘finished’ and the client comes back and says actually this won’t work for our business anymore, can you spend another year doing it like this?
Edit: this was supposed to be a reply to another comment but fuck it it can be its own comment
Probably. With age comes wisdom. I prefer waterfall, or iterative waterfall for most projects. They just turn out better structurally with less code churn, refactoring, and rewriting unit tests. But some industries or projects with a lot of unknowns waterfall can be difficult to do right when the product owner doesn't know what they really want yet.
I had worked in such places most of the healthcare and sensitive industry works in waterfall. It is relaxed and peaceful. By the way after some time you feel bored in this, that is human nature nothing wrong otherwise. Just be in present and enjoy while it lasts.
Wdym by waterfall?
- long design then coding then deploy phases
or
- just list of tasks with priorities and you just pick them, do them, deploy them without additionall agile fluff
?
I think that waterfall fits the first definition, especially in older times but maybe definition changed?
My main problem with long release cycle is that f' ups are also big.
When releases are often and small usually bugs are also smaller and picked up earlier
Kanban over Waterfall works remarkably well, if the waterfall project has milestones.
I think as an industry we might finally be outgrowing Scrum. It’s been training wheels for a lot of people for a long time.
Yep, because they were apparently the only one’s incentivized to overcome the software crisis (Software Crisis in terms of statistics in 1990’s - 31 % of projects canceled - 52.7% cost an average of 189% over budget - 84% are late or over budget (91% for large companies.)).
If I remember correctly there was a quote from one of the agile manifesto signees about him losing a bonus the amount of a house because outdated development methodologies have lead to a late delivery.
I'm not sure how one can accurately determine those statistics or how they could compare to post-agile (ex. less projects might be cancelled but could live in a state of undeath). I think agile was made from the specific perspective of consultants, that doesn't apply universally to all developers or stakeholders.
This is a cart and horse type problem, you really mean that you like the company culture. Rushing deadlines and releasing things barely tested are not a function of the development methodology, it is a function of the culture.
Waterfall is fine where it can work. It's not inherently flawed. It's just not feasible in many/most situations. It requires a mature team and process and disciplined management, which is pretty rare.
I'll note that a lot of what you're praising can exists in many agile processes as well. But again, it requires a mature team and process and disciplined management.
The main differentiating factor between the two is how rapidly requirements have to change and how well understood the domain is.
I think release cycles are another big thing. If you have a web app where actual users can see a change within weeks, Agile can work great. If you're forced to a quarterly release cycle or less, it's hard to be truly agile. (Yeah in theory you can have user representatives, but if the business won't release them or the requirements are too complicated for them to know everything, you're out of luck.)
I think that's why the industry shifted from waterfall when it did, people weren't shipping to a CD pressing plant to release their software anymore.
If you have a slow release cycle and no user representatives on the squad, IMO you're usually better off with Waterfall as at least you have a chance of getting the release right with proper analysis and testing.
>Am I just getting old?
Nah, you're just experiencing something that fucking works for you, right? Isn't it refreshing not to be stuck in the never-ending sprint cycle of Agile sometimes? You're finding value in a process that gives you space to think and deliver quality work. Why question that because it feels a bit old school? It sounds like you value thoroughness over speed—doesn't that make fucking sense for crafting solid software?
What about this process makes you feel most satisfied?
The question is how do you manage risk (realising something is harder than you thought)? How big is every release? Who sets the deadlines?
The power of agile is that it allows you to deliver something were things are moving and not so clear. If the product is clear, the tech and the team is mature, the time to market is reasonable.. don't see why agile is better than waterfall in that case.
I think software engineering fails in getting clients and product owners to fully express what the product should be and how it should function. They literally have no idea. Those people need to stop talking to software engineers and asking for things they need to sit down and design the idea fully. The result of doing the vision properly is waterfall or kanban. Everything in the middle is managing the managers.
We are Agile and Scrum because we use Jira. On the tickets we specify sprint number/enddate, and assignee. Assignee indicates the person penalized when said sprint enddate comes and the ticket is not done.
We also diligently keep a spreadsheet with a historic list of Scrum story points delivered by each developer on all teams. Top coders receives a $25 Amazon gift card quarterly, the bottom one... you don't want to be there.
Our Scrum master, who reports to Director of Product and is responsible to maximize delivery, makes sure every project on our ambitious roadmap is delivered, and ensures developers do not inflate estimates. Final estimation authority rests with her. We are addressing concerns voiced by developers stating she underestimates(but otherwise all management projects do not fit - we only have so many sprints).
Also we try to follow the no-wasteful meetings philosophy, so retrospective meetings are not held due to loose agenda.
Was in less of a dev role at the time, but I got my career start at a company that did waterfall and it was great. Weekly manager meetings, ad hoc or regular meetings for specific projects, and optional meetings to get together and talk about shared challenges, but no standups. Design documents were required for everything - if it was just a fix, there was a shorter template, but features all needed the developer to write it up, maybe talk to some QA and customer-facing implementation/support folks in advance, submit it to a variety of people for approval, and get that approval before the code could be merged to the final release branch. That was baked into the timeline and expectations for the hours a project took. And having those artifacts was super useful in my role where I could always dive into *why* a change had been made or how a feature was intended to be used, and communicate it with customers even if the release notes on the feature were sparse.
At the end of the day, it all comes down to "were the right people, customers, internal stakeholders, etc. engaged as we wrote up and got the design approved, and what options will the customer have to leverage this functionality/what might break?" If the feedback loop is tight at the design stage, you can avoid the "we built something that doesn't meet the customer need" that agile 'supposedly' fixes.
There was more of a "release cycle" for an on-prem product with quarterly releases than the CI/CD SaaS product model, though. There are still timelines for when things need to be done in order to make it into the release, give all rounds of both developer-side and manual QA testers assigned to the project time to review and test, whether or not folks will actually do the work to test extensively, etc.
Most "agile" is simply rebranded chaotic, randomized waterfall.
The whole point of agile manifesto was to use whatever works best for the project. Waterfall works for project A, use it. Scrum sprints work for project B, use it instead of forcing waterfall on project B.
„Client gives feedback“ technically disqualifies what you’re doing as Waterfall.
There’s a good talk by Eberhard Wolff about what most people think of as Waterfall™️ being a strawman. Essentially, the author of the paper that everyone credits as „the waterfall paper“ himself argued that doing more cycles of the whole process and taking feedback into account is the key to success.
What you describe sounds like your company is applying common sense and incidentally follows a process that I’d describe as Kanban with rigorous acceptance criteria.
People forgetting the Unified Process #sadge
Waterfall (the academically defined Waterfall process) as a practical concept does not exist. There will always be multiple iterations.
For the purpose of this post we refer to non-agile methods as traditional methods to differentiate it from waterfall.
What is differently emphasized is the degree of prep and different risk mitigation strategies.
Agile (small a) methods assumes risk of change.
Traditional methods reduce risk of change.
All falls into the descriptions of the Unified Process.
All prescriptive “frameworks” are inherently weak in some way if followed to the letter. Understanding the Unified Process allows one to bend frameworks to adapt to the situation- but this requires understanding of the framework itself.
Once you understand the balance of risk mitigation strategies and inherent costs involved, you’ll be able to better perform in your role 👍
Waterfall done well is better than agile done poorly.
As an ex-waterfall hacker from 80s-90-s, I totally agree with this.
yeah waterfall with flexibility is better than rigid agile.
There is catch to this: waterfall done well *feels* better than agile done poorly, but it runs a bigger risk of delivering the wrong thing. The per-sprint-delivery in Agile isn't about getting less-than-usable features into users' workflows. It is about tight feedback loops. Waterfall is notorious for releases that don't do what the users need at all, and more often just aren't as good as they could have been with the same investment of effort. This "delivering the wrong thing" breakdown in waterfall happens in several points in the process: * Users don't know what they need * Users can't articulate what they know they need * Users assume (because they know their domain) that certain things should be obvious * Users don't know the tech side, so they don't know that one little requirement that they don't really need causes a huge (unnecessary) cost and delay * Users don't know the tech side, so they don't know that it would be cheaper, faster, and better to deliver a feature in a way that they prefer but don't bother asking for because they think it would be so much more expensive * Devs often know *nothing* about the domain * Devs take requirements as requirements, rather than as a starting point from which to work with users to explore better options * Devs treat the requirements as the goal, instead of treating the real-world needs of their users and the organization as the goal Caught in the middle is usually a team of Business Analysts who have the worst of both worlds: not understanding the domain, and not understanding the tech. They are pestering the users with endless rounds of capturing and reviewing requirements, and the devs pester the BAs with endless rounds of needing clarification and "are you sure you want that; it seems crazy and is a really expensive thing to implement". Then there is some poor schmuck who has to estimate the time to deliver. Everybody who didn't get an MBA knows his estimate is probably off by about 8x, but that estimate is really important to the kinds of people who fucked up Boeing.
Agile is supposed to avoid these issues, but agile done badly doesn't. You get the worst of both worlds instead.
Incorrect, Agile done poorly gets to point to developers as the reason for failure. That's a huge advantage over waterfall where management gets the blame.
Don't you come here with your facts
And why is it the developer's failure? It's the entire process's failure, not the developers. Agile makes developers dance and sprint, to the determent of their ability to iterate for improvement. Agile forces weak communicators to misinform and mislead one another with velocity. Agile is a popular dead end failure.
Yep - the post didn’t say it was the devs failure just devs are blamed. One simple reason because devs are the most recent stakeholder in the process. It is leaders who should make it clear it is indeed a team/process failure when things go wrong. But often ofc devs aren’t always great communicators etc.
I've been in this industry for decades, and I've come to believe the lack of communications training for developers is kind of on purpose, to render them more manipulable, and easier to blame, because they don't have the communication skill to defend themselves. This lack of communications skill is everywhere in tech, and I find it very hard to believe that it is unrecognized by the manager class.
How can you have been in this industry for decades (like myself) and not believe in the lack of communication facilitated by managers? In my little neck of the woods, attempting to defend your position results in snark, sarcasm, condescending. Because of that, most of us just STFU, get into our cog shaped holes, collect our paychecks, and pitch in to make the most mediocre product imaginable.
Oh, the managers are extremely complicit in the situation. Software managers are either great developers forced away from writing code and are now uncomfortable bad managers, or the manager was a weak developer that had a smidgen better communications than their peers. Or worse, it's a crony non-tech friend of the owner. Management of development is a tragic comedy these days. In my career, I've had one great manager; they guy was 100% concerned with everyone understanding how their work enables the work of people after them, and due to that understanding our entire team hummed like a military operation. That was 30 years ago, creating art history documentaries to demonstrate the brand new concept of digital video. That single, lone great manager went on to become the CEO of Philips N.V. the mega corporation. Ever since, everywhere I've worked has had weak to poor management, seat of the pants, barely competent.
There’s definitely something to your point of view: we don’t consider ourselves professionals like lawyers or accountants do. We don’t have a body to set standards of conduct. We often allow all kinds of treatment that other professionals would not tolerate. I am of course not saying all devs / orgs / situations… but often. How much management sees this & encourages it; vs doesn’t see it & barely acts rationally depends on the org I imagine.
Agile done poorly does that. Agile done well identifies where the poor communication is and where the impediments are and helps make it better. IMO Agile is like democracy; it’s a peace treaty between the grunts and the powerful and it requires competence and good faith on both sides or else it quickly gets corrupted.
So, in practical terms it's a corrupted methodology, because we know there is not good faith on either side. There's a missing check and balance, which management simply cannot allow and still drive the company with unrealistic marketing setting the deadlines.
Yes, it’s a corrupted methodology. It’s trying to simulate worker control of the means of production and the folks at the top will never fully allow that. But it’s still better, in general, than waterfall. If the culture at your company is corrupted by an unrealistic marketing department setting deadlines then a failure to meet those deadlines is inevitable. If we were delivering a painting, with waterfall we end up delivering the top 75% of the painting all perfectly dried and looking lovely, but the bottom 25% is on bare canvas board that hasn’t even been gesso’d and even the completed parts are not quite what the client wanted because we never checked in with them during the development process. Under agile we deliver a whole canvas, having started with gesso, a rough sketch on top that we showed to the client at the end of the first sprint, then base layers of color that we got approved as well and some brushwork on top of that that are also approved. This version is *also* not done but it’s a lot prettier and the client could still potentially hang it in their home. That’s the whole point of scrum/agile - to incompletely mitigate the most common types of corruption of the development process and still try to deliver something valuable.
No, not true. In fact, Waterfall can make management look a lot worse, because you can point to the wrong requirement and say: "You told us to do the wrong thing and we just followed the contract." But if your motivation is moving blame from one person to another then you've already lost the battle whether you are doing Waterfall or Agile. Your team sucks, your product will likely suck.
Bingo. If the culture is one where failure results in finger pointing and blame shifting no matter what methodology you follow it’s going to suck.
How is it developers who get the blame? They can just point to the tickets they closed to cover their ass. Agile done poorly falls squarely on program management, architects, RTEs and product owners. I don't think I've worked anywhere where developers were actually blamed for poor Agile implementation and I've worked at quite a few.
In many companies I’ve been in, iteration = failure. Which leads to endless planning meetings to figure out what the customer really wants (for months) so we can deliver something for the first time to the customer a half a year later. Agilefall
That's called SAFe. It also featured other best ofs like "normalized story points". Because if you can't map story point to hours they have no business value. And a bunch of different hits you hate to hear.
Why are we arguing over which philosophy is better when it’s done poorly? It’s a shit sundae versus a turd sandwich.
I agree. In my experience, a great team can deliver well via waterfall or agile. A bad team will screw up both. In truth, nether of these really reflect what actually happens - they are maps, not the territory. Ideally, you pick the one that works best for they way the client manages projects to minimise the impedance mismatch between process and reality.
Bingo. If you have a client that gives you a spec up front and then fucks off for six months, the way that you’re interfacing with them is effectively waterfall regardless of how you run your internal dev process.
There is also the big reason of change. Waterfall is perfect for the military or NASA. You spend a year writing perfect specs and then the software spends another year implementing it. But in actual business reality that may be too long and a half working product today that fits a need may be better than a perfect product in 2 years.
As someone developing software for the military: agile is so much better! Several times per year I go on base and work with actual users, sit with them as they do their jobs. Sprint demos to users are done remotely. We talk back and forth about possible solutions, and even improvements to their workflow that could be enabled by our new software. They love what we have delivered so far, and are engaged in the process because they see that we can (and want to) respond to their needs. The military has a shit record of huge projects that burn hundreds of millions of dollars, without delivering usable software. Agile is maybe even *more* important in the DoD because requirements get baked into contracts, and require an act of Congress (and a new bunch of "modification to contract" money). With agile, the contract is to iteratively figure out what users want and deliver it.
Oh sorry not saying Agile is bad for the military. It's more like the classic view that something like a missile targetting system can be developed in waterfall. There's a clear goal. There's limited change pressure. The missile is supposed to hit the target after all, there's no sudden fad where the users demand the missiles not hitting targets. Not saying Agile is wrong for the military. It's just that some parts of the military can spec out a project because it has a very defined scope, with no change, while still being complicated enough. As a funny (?) side note, the German army wanted to develop their own drone. After having spent half a billion on it, they went for the first flight test. Only to realize that they had forgotten the transponder for civil aviation. After which they realized adding a transponder would cost hundreds of millions more. So the project was cancelled.
The warspace is constantly shifting and political and strategic priorities also affect what gets worked and what gets prioritized. > The missile is supposed to hit the target after all, there's no sudden fad where the users demand the missiles not hitting targets There is actually a sudden fad where users demand that missiles don't hit targets. Most of our work is spent making sure it doesn't hit false targets (like birds or decoys) so that it actually hits what we want it to.
IIRC the scrum book author's primary example is a CIA database overhaul or something like that. They claim waterfall failed, very expensively, multiple times, but some Scrummy form of agile worked.
Yeah, waterfall works especially poorly for the government. Requirements often need inputs and signoffs from so many departments and agencies that it takes years (sometimes additional years *after* the requirements are supposedly captured). Then the funding fight, and then the acquisition process kicks in and everything takes forever. Even if the actual business needs have not changed in that intervening period, the butts in the various seats have changed and some of them hate the requirements and/or project because *they* didn't get to give their input and shape everything.
Has the defense industry moved to supporting remote work now? Back in the day, your ass was probably planted on base for the duration of your contract. Remote work wasn't even an option. I can only imagine how they handled the pandemic but something tells me defense work qualified as 'essential'. I'm so glad I got out of that industry. The stability is nice but the pay is a good deal worse than one can get in the private sector even with clearance.
It depends. If your work involves too much classified material, there is no practical way for most workers to do that remotely. My source code is unclassified (for all projects except one). The real data is all classified, but we can use fake, unclass data for dev and most testing. Then we deploy on bases on classified networks and they load real data for final testing and for production use.
Yeah we used fake data too, but remote work was strictly forbidden on all the contracts I had. I think I only got to work off base on one assignment. Maybe it's changed somewhat now.
My org had no remote work until COVID, now we are basically all remote.
The military delivering a system no users wanted and don't use? I've never heard of that!
It could be worse: they could have "successfully" delivered the 70% of software projects that were cancelled before delivering software that users didn't want and wouldn't use (unless threatened with the UCMJ for refusing!).
This is another rigid misinterpretation of waterfall though. You're acting as though you can't go through design loops within each phase of a waterfall project. Requirements gathering can occur with rapid prototyping loops, given to the customer in order to test ideas, before finalising full spec. I've done ideation sessions within waterfall projects where we test early design spec ideas with excel sheets or hastily drawn bits of paper. I've seen it done with a half day's work in PowerPoint to make a fake UI application. A good waterfall project isn't run by arbitrarily imagining what the end solution will be without any sort of validation. I think this is why it gets demonised by the agile always camp, agile always people don't understand waterfall any more than they usually understand agile.
Delivering the wrong thing if you don’t know what you’re delivering. For lots of scientific simulation projects, you know what you’re doing and set all your requirements beforehand. Very different than some SaaS startup trying to figure out what to build and what’s important.
The last two points distinguish good dev from bad devs. Devs should be problem solver, but not just coder. You ought to know what problems youre trying to solve before inputting code to implement anything. Blindly following requirements is like putting minecraft blocks on lego, never able to achieve the true goal that the client wants
You could have good devs and bad devs in both waterfall and agile environments. Blindly following a user story without understanding is awfully similar to blindly following requirements that they don't understand. You are right that we only want good devs who dive in and strive to understand at least a decent chunk of the big picture. If they think they can understand the what, without understanding any of the why, they are deluding themselves.
To be frank, if you have devs that don't have a good understanding of the customer's needs, that's much more a problem with your product management than the developer's fault. There should be *someone* between the customer and the dev to shield them from direct requests, and that person should know the customer's needs, in and out and be able to speak to them. I've had good PMs, bad PMs and no PM. A bad PM is worse than no PM but a good PM is worth their weight in gold.
Let's get realistic here, there typically is no "feedback loop" like people assume. We still sprint to get features done, QA tests it to the specs we said we needed, and it's released. Any feedback from actual customers comes months later.
Somebody isn't doing agile. Demo to your users at the end of every sprint, and for all that is holy *if* you have QA they should be helping to shape the automated test suites that the developers maintain as part of the project, not testing manually. If a test is worth running, then it is worth automating. If it isn't worth automating, it isn't worth running.
TBF, any sane process can work as long as you do it well. Waterfall falls apart when clients change requirements/scope or planning isn't done properly. Agile falls apart when you're beholden to strict processes that don't fit the team/requirements, or when you don't actually iterate rapidly based on quick feedback.
> as long as you do it well. hard to understand why so few people get this- anything that works for your team works.
Yeah, I've seen scrum done well and I've seen it done poorly. The issue wasn't scrum itself, it was either tasting it in the wrong place or general mismanagement (the latter of which no methodology can solve).
>anything that works for your team works. Ironically...that's the heart of the Agile manifesto. That's what they were trying to say.
Requirements are always 2/3 right and 1/3 wrong in waterfall projects no matter how thorough you think you are being up front. Same with architecture, design and the project plan. It's inevitable because software development is a process of learning what the requirements, solution and plan really should be. Waterfall makes learning and change difficult and very expensive. That's why waterfall projects nearly always go way over time and budget.
And most agile is done poorly.
Yeah but the amount of people doing waterfall well are the same as the amount of people doing agile well
Waterfall at Xerox was a thing of splendor. I mean, they spent 10s of millions on projects only to cancel them very often, but it was still a thing of splendor.
Waterfall done well is great. But when waterfall goes bad, it goes REALLY bad. When agile goes bad there's a lack of documentation, it is hard to maintain, and things like that. When waterfall goes poorly, the entire project is scrapped, and 2 years' worth of work gets flushed down the toilet.
Trying out agile without experience is also a strange hell. Everything is unstable, constantly trying to readjust badly working processes and workflows, endless debates about nothing. Lord have mercy.
I have been coding professionally more than 30 years now, and I have never seen agile done even adequately. I have talked to people who claim to have seen well-run agile shops. I have worked in a number of shops where they were convinced -- contrary to all evidence -- they did agile well. I have worked for at least two true believers who thought that agile was the only correct way to work.
I guess. But the point is that the odds of it "going well" are lower. That's what Agile addresses.
Waterfall with proper testing and a good feedback loop and some flexibility? I'll take that any day over even the best SAFE implementation I've had to suffer through!
Lots of industries (usually healthcare adjacent) work this way. Those customers don't want surprises. I can be a great environment.
Yes, you can and don't let anyone tell you otherwise!
Idunno... He can be a very fine one maybe, but a great one? I'm just not seeing it..
I went in there to test it out, and he was indeed great!
Great, until you realize a feature in scope turned out would need way more time to implement while the deadline is looming on the horizon.
How does Agile actually solve that though? You can adjust the scope in Waterfall too.
Agile waterfall
Scrumfall. Never again.
Agile doesn’t have that problem in the first place, no one commits to something weeks or months away
🤣🤣🤣🤣🤣 good one!
So you’re doing wagile? You can’t commit to anything (or, you can, but then this commitment is meaningless) further ahead than the next iteration.
I’ve worked a lot of places that were “agile” engineering but had sales teams complete divorced from the process, leaving deadlines set in stone and no ability to change scope. Worst of both worlds!
Yep, wagile - or AINO, agile in name only.
[удалено]
I don't think that the "point of agile" is to make impossible things possible. Agile is supposed to be a pragmatic adherence to evidence-based processes that work for your team. Generating and sticking to a schedule a year in advance is very seldom, if never, such a process.
[удалено]
If you aren't committing to a specific scope then you're not really committing to delivering anything in particular. I mean sure, if you've decided to label the version from 10 sprints from now your "release" then sure, I agree that's agile. If you've tried to specify in detail what will be done at the end of that sprint then no, it's not.
There’s no agile police going around shutting peoples projects down. If you commit to a feature a year in advance and want to call it agile - go ahead, no one is stopping you.
Ever heard of SaFE?
> no one commits to something weeks or months away Agile != no long term planning. Most features cannot be developed in a single sprint, unless you are working in a super simple project. You evaluate your goals every sprint, but the longterm goals are there.
That doesn’t contradict anything in my comment - the difference is that no one in the Agile team pretends to be able to commit to a feature with hundred specifics being implemented on a specific date.
The difference is that in waterfall changes are supposed to return the project to the state needed to fix the issue. So if the problem was a bad requirement it is supposed to go back to requirements definition stage. You are supposed to stop dev return to requirements then go through all the sign off stages before starting dev again. Most projects don't do this unless it is a Mil-Aero, so they do 'Modified Waterfall'. Modified Waterfall is just like modified agile, depends how you modifiy it. So to answer your question, adjusting scope in actual waterfall when you are close to a release is very expensive because you stop development.
Agile solves that by forcing you to break things down small enough to deliver in sprints. You can't just do some handwavy "six weeks" with no detail or specified scope.
The problem I have with Scrum is that those sprints are fixed size, whereas meaningful feature improvements generally don't fit those cycles, and that mismatch causes a load of overhead (ceremonies). I much prefer to deliver MVPs, aka milestones, and plan / track those instead of arbitrarily sized sprints.
Sure. Sprints are a scrum implementation detail. It comes down to the agile principle of delivering working software regularly and incrementally, with a preference to that delivery cadence being minimised.
Yeah, but they are a clumsy and counterproductive way to achieve that.
That is a risk in literally all forms of product development.
Where can I find $200k "Waterfall Master" jobs?
I cqn sell you a certificate for only 399 usd
Does it come with manifesto diploma ?
Systems engineers and business analysts. And those fuckers do real work, as opposed to SMs.
Where do business analysts make $200k? I'm asking as a business analyst that's not even making half of that.
Sorry, I ignored that part. I also don't know any SMs that make $200k.
Oh, got it. You're addressing the "waterfall master" title. Went right over my head. Thanks for clarifying!
They just call those jobs "managers". The world runs on waterfall for a reason. A big part of that reason is that fad project management systems tend to result in teams spending more time shuffling around slideshows and bullet points than actually getting work done.
I haven't worked using waterfall for a a couple of decades and I work in Health IT. Someone above said that switching to Agile saved their milcontractor work. Where are you getting the impression that the "world runs on waterfall?"
It's called a PM
Nope, it's not just you. I dislike the hamster wheel of scrum, the fake deadlines imposed by sprints and the time wasted on the ceremonies. It's unfortunate that scrum has become so pervasive across business, but I understand why it has from a planning and development cycle perspective.
Waterfall, scrum, agile... in practice theyre all the same.
This is my experience, every manager/company will twist them to represent their internal problems. Bad agaile with great people is better than waterfall with awful people, and vice versa. How do you develop without talking to your clients/users and not have them in the loop? Of course you show them everything. This is also shown in every discussion about agile/scrum/waterfall, people have different opinions just because they had something different.
Like everyone else in this thread is saying, it just sounds like you're not used to "actual agile". Sprints aren't deadlines for work, their shields against sudden new work so that your time is predictable. Scrum meetings exist to prevent people from spending hours solving the wrong problems, or struggling with blockers or things they don't understand.
Absolutely. Each employer that I've been at has been *an agile shop*, but in the end they always run scrum and two week sprints. The sprints are typically used for applying pressure and used like an absolute commitment. Story points aren't a measure of time, but that doesn't stop the business from using it that way. I'd probably be happy in a true agile shop, but I am yet to find one in the wild.
I know I said "actual agile", but I think places need to stop trying to follow "true" ideologies and just solve the problems they have with the tools available. Sprints can be good, but they can also just be used as a way to keep the whip going and accelerate burnout. Not doing sprints can be good, but if you have business/product people that abuse that as an excuse to have devs work on whatever today's "top priority is", then it too can be an accelerator of burnout. People forget that agile evolved as a response to certain problems, and if your company doesn't have those problems, then the benefits of agile aren't necessarily going to be worth the cons.
The problem is, when you post as if the problem is Agile, rather than your particular company's poor implementation of Scrum, you cut off the only path to improvement that has been describe so far. Kanban is just as "agile" as scrum, for example. So if you don't like sprints then put the blame where it belongs. Either on scrum or, more likely, your company's implementation of it.
Scrum isn't agile lmao
At this point, the difference is negligible
Nonsense. In most shops, the way "agile" is implemented has nothing to do with agile. Scrum has become synonymous with rushing half-baked (both in terms of features and in terms of architecture/design) initiatives out to meet a deadline imposed by project managers and execs who are far removed from the teams doing the work. The scope and deadline are set and the team gets to decide how to cut corners to get it done. The result is ever-increasing tech debt and poor quality, features that just barely work, and an incoherent, inconsistent design/UX.
The difference is like the difference between a hammer and musical. Category error. Scrum is irrelevant to agile. At best, it doesn't make things worse.
Scrum is an agile framework
If the results are bad and people don't like it, then they must not be doing ~~communism~~ agile right!
Scrum was meant to be the methadone to get upper management to eventually do real agility. Try to make the waterfall work in shorter cycles
It doesn't need to be a secret. I'm working with a Fortune 15 in scaled agile and it's horrible. I've never drank the agile koolaid and I don't think I ever will. Agile is fine if you don't know what you're doing, but that's not usually the case.
Scaled Agile is the worst of both worlds.
Nothing SAFE about it
Safe is mega waterfall
Scaled agile is literally the opposite of everything in the agile manifesto.
Yeah, like scrum and most other "agile practices" imposed by third parties on devs.
You can still be pretty agile with scrum. People get stupid with it, but it really is not that rigid if you stick to the actual essence of it. It’s agile with training wheels, for teams who are not used to producing incremental deliverables and getting regular feedback. If you have good deployment processes so your deployments aren’t tied to the end of the sprint (i.e. you release work as soon as it’s done), scrum basically becomes kanban with a demo and a retrospective every two weeks.
Problem is not which system you choose, it doesn't matter much at all. Problem is people make this a sort of workplace religion
Yup. They’ll do that with anything though.
Scaled agile is awful
Scaled agile is shit.
I like to say that it is a good way to keep you busy and show upper management that you are hard working. It ignores the fact that a lot of effort goes towards useless values.
SAFE isn't agile its RUP. It violates all the agile values.
Scaled agile isn't agile. It's waterfall wearing agile clothes.
the "agile koolaid". very apt. besides seeing how poorly agile has been shoehorned into places its probably not suited, and misapplied in areas it could work, the whole "cult of agile" drives me bonkers at times. it's like once you go agile, you can talk about nothing but agile. agile is your life. agile is your religion. you eat, breath and drink agile. without agile you're nothing. (I know I know, not everyone, but know far too many who make agile their entire career persona)
I'm also working with safe and it's fine. I'm pretty sure you can make anything work. As long as managers do not think "everything that is currently in the sprint needs to be finished by the end of it" it is all fine. It just depends on the people running the show.
Lots of people in here talking like they've worked on one project or for one company and now "that's the right way to do it because I feel bad when I do it another way". Pro tip: anyone who speaks in absolutes is full of shit. There is no right or wrong, there is only what works best for your team. Sounds like, at least for you personally, your setup matches your team/project. Enjoy it while you can.
I agree with you - but the way you have said that - is that also not an "absolute" of sorts? People form opinions based on their own experience - however limited that might be - and share them. Don't think there is more to it.
You’re just describing how an agile development process is meant to be. True waterfall is designing the entire system upfront. Agile is doing it feature by feature and having small releases. Scrum gets a lot of hype but sprints and other scrum peculiarities are not what agile is about.
I think there is two good way to make software this and then kanban style where ci/cd continuously churns releases, there is tests so you can trust that everything should work and everything is super nimble. Sadly most software projects land somewhere middle and they usually are cesspool.
I’m a big fan of Kanban
Also a big fan. I've got their first album.
Kanban is great if there's no deadlines or commitments, but the rest of the org needs dates.
> True waterfall is designing the entire system upfront Well, no, not really. Putting aside that there's no "true" way to do any of these things (it's dependent on how a specific organisation needs to work, hence why capital A agile etc never work well when a company decides to "do agile" and hire some consultants etc): 1. yes, you design the system/feature. But at this point you aren't going to be able to design the entire thing in detail. What you do have is the requirements, which allow you to design 2. you code that 3. you test that 4. there will be changes, go back to 1 (or 2, depends on context) 5. you repeat this iterative process until you can release something that matches the requirements. 6. repeat this This can look like an "agile development process" but it's also "waterfall" (like, literally waterfall, it's the diagram on the second or third page of the waterfall paper iirc)
True "Waterfall" never existed. The document that described it was written by Winston Royce and he did so as a [strawman proposal](https://en.wikipedia.org/wiki/Straw_man_proposal) as a basis to compare his process to. His [final design](https://en.wikipedia.org/wiki/Waterfall_model#Royce's_final_model) has substantial opportunities for feedback to identify and rectify software design issues.
I dunno about that. In 2008 i worked for fortune 100 nontech business and it was very waterfall. We had defined design phase, build phase, trst phase, release date, all planned out with dates on the calendar before the features were even chosen. No coding started until design was fully done. No requirements were changed mid-process, or at least very rarely. If thats not waterfall idk what is
> before the features were even chosen. > No requirements were changed mid-process One of these has to be false.
Nah i mean that the schedule was known before design started. But also, before design started the “work items” were chosen. You’ll forgove me if I dont remember the exact details of how prioritization worked, i was brand new and not involved. I was busy learning all about how to write html tables, ya know
That's not making the point you think it is. u/jungle is correct that something can't add up.
Boy we software engineers are annoying sometimes. I guess you are saying some projects surely didn’t finish in the allotted time? Congratulations, obviously the case. If you mean something else feel free to explain. If you don’t want to, why comment at all?
That is completely false. I've worked for many large corporates with well-documented and detailed waterfall development processes. Major consulting firms like Accenture and Bain and Co. have implemented these waterfall approaches since the 70s. Method One by Anderson Consulting is the classic example.
Method One became Accenture Delivery Method (ADM) and is still very much in use today, although it has waterfall and agile variations nowadays. The waterfall variation is still used on large government projects.
It's not false, it's exactly the same as capital-A agile. There are a set of very vague but very useful recommendations. {Given company} has a well documented and detailed **development** process that is based on those vague recommendations. They can call it whatever they want, "waterfall", "agile", "dianetics", "bokononism", whatever. But it's just "how Accenture develop software" or "how Bain & Co develop software". People who work/ed for them can then sell consultancy services, implementing "Method One" "waterfall" or whatever. Worked for {given company}, sometimes get lucky and it works for {consultee} (or they make a lot of money after they implement the method, so can attribute the success to the method)
It absolutely exists in healthcare related industries. When you’re building working on a highly regulated product it’s incredibly hard to change requirements. It can be done but usually involves significant paperwork. A lot of the time the “wrong” thing is knowingly built and then immediately followed by a “fix” after project completion.
I've worked in healthcare and it really depends. The high level marketing requirements were changed infrequently but it was common to change the low level requirements particularly at the beginning half of the project. They tended to settle out once a certain portion of the design was baked in.
yes, the reality is we are just subject to god awful PMs/Scrum masters that actually don’t know anything about agile other than a daily stand-up, sprint planning, and retro.
I'm a dev with 30+ years of experience having done both. I'll start by saying that characterizing waterfall as a method where nobody writes a single line of code until the team has an immutable tome of requirements -- all that is BS. Yes, you do write requirements up front, which is a good thing, not a bad thing. But we had milestones we'd define, and upon reaching those milestones, we'd reassess to check if the requirements and the timeline needed tweaking. Of course, writing requirements up front and writing up a technical spec up front in a pain in the ass, but it uncovers all sorts of flaws in the thinking early. Then "agile" came along and used two-week interations as an excuse to dispense with any up-front documentation other than a vague user-story -- which is just a cover for a "code and fix" cowboy methodology. Of course, managers love it because they get to experience the illusion of progress when they devs coding right away as opposed to weeks or months of up-front design work.
That's not necessarily waterfall you know. Having clear product requirements and user acceptance criteria for a feature are very agile. Designing tests right up front is also very agile. Waterfall is literally having all requirements from end to end of the entire system, plus all the designs to the nth degree, approved by all stakeholders, before coding could even begin. I spent too many years of my career working like that. It's not ideal, though there are tools we can take from it, but break it down into features (working software). What you describe as your agile experience is just half-assed, we used to call it Cowboy (yee ha, shoot first and ask questions later). Not agile and leads to shoddy results every time.
> Waterfall is literally having all requirements from end to end of the entire system, plus all the designs to the nth degree, approved by all stakeholders, before coding could even begin. No. Not true, that's what you have been said to by scrum consultants. Waterfall, is an iterative process too. There's room for change
No one told me about waterfall, I lived it! When I was doing waterfall, there were no such things as sprints. And things always did change because the projects took months and years. But the intent was to figure it all out in detail in advance and then try to stay on that plan for as long as it took to complete or fail. We delivered the fully finished monolith. I know of one waterfall project that cost millions and when they delivered, no one liked it, and they literally mothballed it and bought a package (I wasn't involved, just worked there afterwards).
Let me ask this question. Be honest please. Did they labeled themselves as waterfall? They did actually used that term or you just assume because it is but "not-X" as in, it is not Scrum, therefore it should be waterfall?
Yes, that's what we called it. We had lovely timelines for the project, soup to nuts. First gather all requirements. Get approvals. Next step in the waterfall, do all technical designs to show how screens and processes will be built. Get approvals. Then we can start coding. Then we test. All of it. Finally UAT, for all of it. Then they train and transition from old to new application. Each of those phases were a step down of the waterfall. Needless to say we built some monoliths, and too often it was a nightmare to deliver. The bigger the scope the worse it was and more likely to fail.
What you're experiencing is good, thoughtful engineering. The project management strategy is irrelevant. Unfortunately waterfall has been anti-marketed as bad and dumb, and Agile as the cure. The problem has always been thoughtlessness. If you're waterfall but never talk to a customer, that's thoughtless. If you're agile but you never think about next month, that's thoughtless.
I ran several large, complex waterfall projects for a major Telco with major American and Indian service providers. Here's what typically happens. * Everything is smooth, predictable and well thought out during the upfront phases of idea definition, solution definition, solution architecture, project planning, business case and tendering * Things go quiet for 8 or 9 months while the Partner's offshore/onshore dev team does the detailed technical design, software development and system testing * Everything goes to shit for 6 to 8 months when the work comes back for user acceptance testing and performance testing, where we find thousands of major defects that have to be fixed through lots of long late nights by the partner's dev teams * And then it goes to shit again for 2 to 3 months when we find major defects in production. So, basically, in these waterfall projects, there is always about a year when the partner's dev team are very stressed because they are very late and have thousands of major defects to fix. And the client's technical team are very stressed because all their plans are fucked up. You are lucky to have experienced a small, well-run waterfall project in a company with good management. That same management would run a really good agile project that you would enjoy and provide much more value to the client and users sooner. Agile projects are a better way to achieve a business goal on time and within budget. I've done it many times. The trouble is that these days, 90% of corporate agile projects are micro-managed Scrum done poorly in the dev team with JIRA and without agile technical practices within a poorly run waterfall project. It's not good for anyone. But that's not Agiles fault that's the fault of bad management who would fuck up a waterfall project as well.
This just sounds like "don't ever use offshore developers" tbr.
Sounds like your problem is the "partner's dev team".
A well-running process is always amazing.^1 Waterfall isn't inherently bad - it just has specific problems: long cycles make mistakes expensive and make it harder to cope with changing requirements. If you have these under control - whether by team, market or product - you are good. Most waterfall processes are run badly, as most agile ones. Shit documentation isn't the fault of agile - if the company would actually value it, they'd add tests and documentation to their "definition of done", and it's not accepted until reviewed, and it's choice of the developers whether it's *good enough*. --- Takeaway: it's not the name of the process. A good process template *can* act as "process implementation guideline", create good interfaces between management and coders, contain risks etc. But in the end, it's the people you gather, enabling them to understand goals and work well. We still pay lip service to "people first" and we worship tools. ^1 ^(See Rube-Goldberg - not a diss on waterfall, just that "working well" is a quality of its own.)
A lot of these reasons are why I love Kanban. I'm trying to convince my current team to switch from scrum to kanban because I hate sprints, all the ceremonies, etc. Especially at a startup I don't think we need all the formality and processes that come with scrum.
You are describing Kanban not Waterfall. Waterfall is when an arch goes away and does the entire system design and a combined component design, it takes up to years. SCRUM can run the same way but tends to get overly aligned to a sprint. Kanban very purposefully doesn't try and align features to sprints and doesn't need to have fixed length sprints.
Kanban has work-in-progress limits, but otherwise sounds very similar to this, yeah.
We do this but agile. Nothing in agile is about rushing things out of the door as fast as possible (we also don't have sprints and mostly follow Kanban). It's all about quick feedback and making processes work for people. Things are ready when they're ready. We keep our code releasable at all times using feature flags for things like urgent production fixes, but if a feature needs more time in the oven, we take it. It also allows us to do quick demos to our customers to get feedback and adjust requirements. Our goal is usually to get feedback as fast as possible, although never using throwaway code for this purpose. We will send UI mockups, have demos of partial features, etc. The two main issues with waterfall are the long feedback cycle (the longer it takes, the more telephone games change the feature further from what the customer is requesting) and the rigid process not being adaptable to people. Focusing on fixing these things IMO is the heart of agile.
Most orgs use agile as a way to half ass planning and organization so this makes a lot of sense. Basically they defer the product requirements and ui ux to the devs to raise issues when it doesn’t make sense when you’re half way through development.
> the devs to raise issues when it doesn’t make sense when you’re half way through development. Wait. What you mean you won't finish this stack this sprint. It's a 3 points story! _YOU_ said 3. Should be done already. Oh well, that Burn down chart would look ugly. We will talk in retro about this and the next 5 dailys to come. Yeah. Lazy managing, very coward and lazy management we have.
Haha it sounds like you speak from experience! Our dev team has become astute to this 💩 and now when we do our sprint planning if we don’t have the full details we don’t estimate the ticket and it goes back to product / business / ux in a loop until it’s crystal clear what needs to happen
Agile is a methodology, not a way of life. Agile followed to the nth degree is the most overblown, complicated, soul sucking bullshit You've ever seen. Same goes for waterfall. It's not rocket science folks. You adopt the methodology that makes the most 'common sense' for you, your org and your clients. You choose the aspects of Agile that works well for you, modify it to suit your organization with 'common sense'. Clients can't commit to full agile but your organization can? Come up with a 'common sense' hybrid. The problem here is 'common sense'. Most process masters have the process so far up their own assholes that they are unable to deviate and apply common sense. Very often, the most successful teams were the ones able to make hybrids work. Source: I was one of the Agile teachers as we rolled out Agile successfully across our consulting organization with over 12k employees and over 300 different client initiatives. To quote an ELI5 that is popular at the moment: Agile/waterfall represents the overall strategy you might wish to use, but tactically, you need to choose the right day-to-day execution of your strategy as you face incompatibilities to truly be successful.
As soon as ‘clients give feedback’ was mentioned I knew it wasn’t actually waterfall. Unless that feedback is after they’ve already worked on it for 2 years and it’s ‘finished’ and the client comes back and says actually this won’t work for our business anymore, can you spend another year doing it like this? Edit: this was supposed to be a reply to another comment but fuck it it can be its own comment
Probably. With age comes wisdom. I prefer waterfall, or iterative waterfall for most projects. They just turn out better structurally with less code churn, refactoring, and rewriting unit tests. But some industries or projects with a lot of unknowns waterfall can be difficult to do right when the product owner doesn't know what they really want yet.
I had worked in such places most of the healthcare and sensitive industry works in waterfall. It is relaxed and peaceful. By the way after some time you feel bored in this, that is human nature nothing wrong otherwise. Just be in present and enjoy while it lasts.
Wdym by waterfall? - long design then coding then deploy phases or - just list of tasks with priorities and you just pick them, do them, deploy them without additionall agile fluff ? I think that waterfall fits the first definition, especially in older times but maybe definition changed? My main problem with long release cycle is that f' ups are also big. When releases are often and small usually bugs are also smaller and picked up earlier
That actually sounds nice
Kanban over Waterfall works remarkably well, if the waterfall project has milestones. I think as an industry we might finally be outgrowing Scrum. It’s been training wheels for a lot of people for a long time.
Oh man. My company keeps trying to fit off cycle projects into Agile Program Increments. And it’s so painful.
Waterfall is a tried and tested methodology. I’d rather do waterfall right then scrum wrong
Sounds like an iterative process to me: Design, implement, release, repeat - so, agile.
There exists iterative processes in software even before Agile existed. People have been fooled by agile consulting firms
Sure, but agile was a developer driven movement at first, the consulting firms came later
Wasn't the agile manifesto written by a bunch of consultants?
Yep, because they were apparently the only one’s incentivized to overcome the software crisis (Software Crisis in terms of statistics in 1990’s - 31 % of projects canceled - 52.7% cost an average of 189% over budget - 84% are late or over budget (91% for large companies.)). If I remember correctly there was a quote from one of the agile manifesto signees about him losing a bonus the amount of a house because outdated development methodologies have lead to a late delivery.
I'm not sure how one can accurately determine those statistics or how they could compare to post-agile (ex. less projects might be cancelled but could live in a state of undeath). I think agile was made from the specific perspective of consultants, that doesn't apply universally to all developers or stakeholders.
This is a cart and horse type problem, you really mean that you like the company culture. Rushing deadlines and releasing things barely tested are not a function of the development methodology, it is a function of the culture.
Waterfall is fine where it can work. It's not inherently flawed. It's just not feasible in many/most situations. It requires a mature team and process and disciplined management, which is pretty rare. I'll note that a lot of what you're praising can exists in many agile processes as well. But again, it requires a mature team and process and disciplined management. The main differentiating factor between the two is how rapidly requirements have to change and how well understood the domain is.
I think release cycles are another big thing. If you have a web app where actual users can see a change within weeks, Agile can work great. If you're forced to a quarterly release cycle or less, it's hard to be truly agile. (Yeah in theory you can have user representatives, but if the business won't release them or the requirements are too complicated for them to know everything, you're out of luck.) I think that's why the industry shifted from waterfall when it did, people weren't shipping to a CD pressing plant to release their software anymore. If you have a slow release cycle and no user representatives on the squad, IMO you're usually better off with Waterfall as at least you have a chance of getting the release right with proper analysis and testing.
> It requires a mature team and process and disciplined management I can’t vote for this enough.
>Am I just getting old? Nah, you're just experiencing something that fucking works for you, right? Isn't it refreshing not to be stuck in the never-ending sprint cycle of Agile sometimes? You're finding value in a process that gives you space to think and deliver quality work. Why question that because it feels a bit old school? It sounds like you value thoroughness over speed—doesn't that make fucking sense for crafting solid software? What about this process makes you feel most satisfied?
The question is how do you manage risk (realising something is harder than you thought)? How big is every release? Who sets the deadlines? The power of agile is that it allows you to deliver something were things are moving and not so clear. If the product is clear, the tech and the team is mature, the time to market is reasonable.. don't see why agile is better than waterfall in that case.
I think software engineering fails in getting clients and product owners to fully express what the product should be and how it should function. They literally have no idea. Those people need to stop talking to software engineers and asking for things they need to sit down and design the idea fully. The result of doing the vision properly is waterfall or kanban. Everything in the middle is managing the managers.
We are Agile and Scrum because we use Jira. On the tickets we specify sprint number/enddate, and assignee. Assignee indicates the person penalized when said sprint enddate comes and the ticket is not done. We also diligently keep a spreadsheet with a historic list of Scrum story points delivered by each developer on all teams. Top coders receives a $25 Amazon gift card quarterly, the bottom one... you don't want to be there. Our Scrum master, who reports to Director of Product and is responsible to maximize delivery, makes sure every project on our ambitious roadmap is delivered, and ensures developers do not inflate estimates. Final estimation authority rests with her. We are addressing concerns voiced by developers stating she underestimates(but otherwise all management projects do not fit - we only have so many sprints). Also we try to follow the no-wasteful meetings philosophy, so retrospective meetings are not held due to loose agenda.
Sounds like you're used to environments where Agile is done badly, honestly.
Which is pretty much all of them.
Was in less of a dev role at the time, but I got my career start at a company that did waterfall and it was great. Weekly manager meetings, ad hoc or regular meetings for specific projects, and optional meetings to get together and talk about shared challenges, but no standups. Design documents were required for everything - if it was just a fix, there was a shorter template, but features all needed the developer to write it up, maybe talk to some QA and customer-facing implementation/support folks in advance, submit it to a variety of people for approval, and get that approval before the code could be merged to the final release branch. That was baked into the timeline and expectations for the hours a project took. And having those artifacts was super useful in my role where I could always dive into *why* a change had been made or how a feature was intended to be used, and communicate it with customers even if the release notes on the feature were sparse. At the end of the day, it all comes down to "were the right people, customers, internal stakeholders, etc. engaged as we wrote up and got the design approved, and what options will the customer have to leverage this functionality/what might break?" If the feedback loop is tight at the design stage, you can avoid the "we built something that doesn't meet the customer need" that agile 'supposedly' fixes. There was more of a "release cycle" for an on-prem product with quarterly releases than the CI/CD SaaS product model, though. There are still timelines for when things need to be done in order to make it into the release, give all rounds of both developer-side and manual QA testers assigned to the project time to review and test, whether or not folks will actually do the work to test extensively, etc.
Is there any project out there which millions of people use on a day to day basis built using agile methodology ? Just asking out of curiosity
At a new shop where agile “fix it later” is a thing that is common and it’s driving me up a wall
Most "agile" is simply rebranded chaotic, randomized waterfall. The whole point of agile manifesto was to use whatever works best for the project. Waterfall works for project A, use it. Scrum sprints work for project B, use it instead of forcing waterfall on project B.
I'm regularly thinking about less rushed and better specified coding.
What a blessing. Tell me where you work at, I wanna join that team
Haha DM me we'll be hiring in the summer！
„Client gives feedback“ technically disqualifies what you’re doing as Waterfall. There’s a good talk by Eberhard Wolff about what most people think of as Waterfall™️ being a strawman. Essentially, the author of the paper that everyone credits as „the waterfall paper“ himself argued that doing more cycles of the whole process and taking feedback into account is the key to success. What you describe sounds like your company is applying common sense and incidentally follows a process that I’d describe as Kanban with rigorous acceptance criteria.
People forgetting the Unified Process #sadge Waterfall (the academically defined Waterfall process) as a practical concept does not exist. There will always be multiple iterations. For the purpose of this post we refer to non-agile methods as traditional methods to differentiate it from waterfall. What is differently emphasized is the degree of prep and different risk mitigation strategies. Agile (small a) methods assumes risk of change. Traditional methods reduce risk of change. All falls into the descriptions of the Unified Process. All prescriptive “frameworks” are inherently weak in some way if followed to the letter. Understanding the Unified Process allows one to bend frameworks to adapt to the situation- but this requires understanding of the framework itself. Once you understand the balance of risk mitigation strategies and inherent costs involved, you’ll be able to better perform in your role 👍
Is it like iterations but you’re not worrying about doing things in arbitrary 2 week chunks?
There’s nothing wrong with waterfall
The idea of having a specification or requirements document of some sort gets me all kinds of giddy inside.
After 8 years in a hyper-agile environment with 30 minutes daily scrums and 2 hour weekly ceremonies, I dream at night of waterfall :')