Comment by 2OEH8eoCRo0
11 hours ago
I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring.
> Most of what's planned falls down within the first few hours of implementation.
Not my experience at all. We know what computers are capable of.
> I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times.
My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for the third time, to get to a much worse product slightly faster. Now we can do that part 10x faster, cool.
The thing is, at every other level of the company, people are actually planning in terms of quarters/years, so the underlying product being given only enough thought for the next 2 weeks at a time is a mismatch.
It’s possible to manage the quarterly expectations by saying “we can improve metric X by 10% in a quarter”. It’s often possible to find an improvement that you’re very confident of making very quickly. Depending on how backwards the company is you may need to hide the fact that the 10% improvement required a one line change after a month of experimentation, or they’ll fight you on the experimentation time and expect that one line to take 5 minutes, after which you should write lots more code that adds no value.
Agile isn’t a good match for a business that can only think in terms of effort and not learning+value. That doesn’t make agile the problem.
My experience in an agile firm was that they hired a lot of experienced people and then treated them like juniors. Actively allergic to thinking ahead.
To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable deliverable or something you could put on a management facing status report.
Each task was so time boxed, seniors would actively be upbraided in agile ceremonies for doing obvious next steps. 8 tickets sequentially like - Download the data. Analyze the data. Load a sample of the data. Load all the data. Ok now put in data quality tests on the data. OK now schedule the daily load of the data. OK now talk to users about the type of views/aggregations/API they want on the data. OK now do a v0 of that API.
It's sort of interesting because we have fully transitioned from the agile infantilization of seniors to expecting them to replace a team of juniors with LLMs.
3 replies →
I think the bigger issue is that Waterfall is often not "Waterfall".
Sure there's a 3000 row excel file of requirements but during development the client still sees the product or slides outlining how the product works and you still had QA that had to test stuff as you made it. Then you make changes based on that feedback.
While Agile often feels like it's lost the plot. We're just going to make something and iterate it into a product people like versus figuring out a product people will like and designing towards it.
There's an abstraction level above which waterfall makes more sense, and below which [some replacement for agile but without the rituals] makes more sense.
I think Qs to ask are.. if the nature of user facing deliverable tasks are longer than a sprint, the tasks have linear dependencies, there are coordination concerns, etc
1 reply →
Agile largely came about because we thought about where we wanted the product to go, and the steps to get there, and started building, and then it turned out that the way we thought we wanted to go was wrong, and all of that planning we did was completely wasted.
If you work in an environment where you definitely do know where you want the product to go, and the customer doesn't change their mind once they've seen the first working bits, then great. But I've never worked in that kind of environment.
It helps to at least write down requirements. And not requirements in that "it must use Reddis", but customer, user, performance, cost, etc requirements.
A one page requirements document is like pulling teeth apparently.
> Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks.
That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.
there is a difference between the requirements changing and the poor quality, quickly made implementation proves to be inadequate.
agile approaches are based on the quick implementations, redone as needed.
my favorite life cycle: 1> Start with requirements identification for the entire system. 2> Pick a subset of requirements to implement and demonstrate (or deliver) to the customer. 3> Refine the requirements as needed. 4> go to 2
The key is you have an idea of overall system requirements and what is needed, in the end, for the software you are writing. Thus the re-factoring, and re-design due to things not included in the sprint do not occur. (or occur less)
This approach also accounts for the truism that "the customer doesn't know what they want until they don't see it in the final product".
> > Most of what's planned falls down within the first few hours of implementation.
> Not my experience at all. We know what computers are capable of.
You must not work in a field where uncertainty is baked in, like Data Science. We call them “hypotheses”. As an example, my team recently had a week-long workshop where we committed to bodies of work on timelines and 3 out of our 4 workstreams blew up just a few days after the workshop because our initial hypotheses were false (i.e. “best case scenario X is true and we can simply implement Y; whoops, X is false, onto the next idea”)
Wait, are you perhaps saying that... "it depends"? ;-)
Every single reply in this thread is someone sharing their subjective anecdotal experience..
There are so many factors involved in how work pans out beyond planning. Even a single one of us could probably tell 10 different stories about 10 different projects that all went differently.
Yeah, which is also why I tried not to* speak prescriptively, unlike some other comments in this thread…
Comparing the same work done between agile and waterfall I can accept your experience of what sounds like an org with unusually effective long term planning.
However the value of agile is in the learning you do along the way that helps you see that the value is only in 10% of the work. So you’re not comparing 100% across two methodologies, you’re comparing 100% effort vs 10% effort (or maybe 20% because nobody is perfect).
Most of the time when I see unhappiness at the agile result it’s because the assessment is done on how well the plan was delivered, as opposed to how much value was created.
> I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring.
That’s not the point. The point is to end up with something actually useful in the end. If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it.
The reason waterfall methodology falls flat so often is not long delivery times, but ending up with completely the wrong thing.
> If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it.
I don’t know. The faster you deliver the wrong thing, the sooner you can discover your mistake and pivot.
You summarized agile. That is the whole point: short feedback cycles. You can view it as a series of short, self-regressive waterfalls.
I think it also depends on how people think. I might be able to sit can't sit in a meeting room/white board/documentation editor and come up with what the big problems is (where pain points in implementation will occur, where a sudden quadratic algorithm pops up, where a cache invalidation becomes impossible, ...) even if I stare at this white board or discuss with my peers for days.
But when I hammer out the first 30 minutes of code, I have that info. And if we just spent four 2-hour meetings discussing this design, it's very common that I after 30 minutes of coding either have found 5 things that makes this design completly infeasible, or maybe 2 things that would have been so good to know before the meeting, that the 8 hours of meetings just should not have happened.
They should have been a single 2 hour meeting, followed by 30 minutes of coding, then a second 2 hour meeting to discuss the discoveries. Others might be much better than me of discovering these things at the design stage, but to me coding is the design stage. It's when I step back and say "wait a minute, this won't work!".
Agile is for when you don't know what you're making and you're basically improvising. People forget that.
Correct, and it was applied top-down to teams that do larger infrastructure / implementations in known areas / etc.
There are costs to pouring out a cement foundation without thinking through how many floors your building is going to be in advance.
But if you don't know what you are making, it is the only option!