- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
Waterfall is more like: You want to go to Mars. You start to build the rocket. Managers that don’t know anything about building a rocket starts having meetings to tell the engineers who do know how to build a rocket what they should be doing. Management decides to launch the rocket based on a timeline that’s not based in reality. Management tries to launch the rocket based on the timeline instead of when it’s actually finished. Rocket explodes. Management blames the engineers.
The various methodologies don’t actually change what the engineers need to do. But some of them can be effective at requiring more effort from management to interfere in the project. Bad managers are lazy so they’re not going to write a card, so they can be somewhat effective in neutralizing micromanagement. I say somewhat, because bad management will eventually find a way to screw things up.
Seems like the author has never programmed anything
Scrum is about transparency, not intransparency for a month
Scrum is not about any of the things that Scrum proponents claim it’s about.
Specifically, it’s not about agility, it’s not about velocity, it’s not about quality, it’s not about including the “customer”, and it’s only about a kind of transparency that has absolutely no impact on the final product.
But yeah, it’s about some kind of transparency.
Specifically, you would have to put in effort to be more wrong.
Go read the scrum manifest.
In reality, companies always adapt for what they think suits them. Very rarely do you actually use scrum completely as intended, that’s fine. But you don’t blame the cow when the cook burned your steak. You blame the cook.
A software engineer was not involved in this if waterfall is painted positively.
I think the last time I heard an engineer unironically advocating for a waterfall IRL was about a decade ago and they were the one of the crab-in-a-bucket, I-refuse-to-learn-anything-new types—with that being the very obvious motivation for their push-back.
I know several who preferred waterfall, but the system I work on is a giant government one and when we were doing waterfall we were in specialist teams working on a small part of the system
At the same time we went agile management also said “everyone can do everything” so we’ve had to work across the entire system
For the rocket analogy: we started building a rocket under waterfall, but when we went agile we also decided that the rocket motor specialists could also work on fuel tanks and heat shields
These are all accurate, except the first Waterfall one, who also doesn’t go to Mars.
Right. They design the whole rocket, spend years to build the rocket exactly according to the design doc, then the rocket explodes on the launchpad and they have to start all over.
We recently saw waterfall versus agile in actual rockets
Blue Origin spent years meticulously designing their rocket. They tested it on the ground. On the first flight it got to orbit, but the first stage exploded while re-entering
SpaceX started building their rocket out of carbon fibre. Changed to stainless steel. Started flying subscale demos, flew high altitude full scale examples to find if their aerodynamics was right, and haven’t actually tried for orbit yet
Blue Origin is trying for a last generation rocket (where the first stage is recovered) but bigger, SpaceX is trying to create the next generation where both stages are recovered
Oh yes, everyone know that waterfall works and the rest sucks, nice
A good team can make any of these strategies work. A bad team will make a mockery out of them all. Most teams are neither good or bad, and stumble forward, or backwards, doing the motions
Waterfall is much more expensive than any of the agile methods, even with good requirement gathering and management
In some situations with some people yes. It’s really hard to separate the project and team.
Usually, projects I have seen start with the best plans and methods, or at least vague good intentions, but later pretend they never met them. Like a cheap date.
There are some projects that naturally lend themselves to one approach or other, and they last longer following the original guidelines ; but if a project lives long enough these guidelines become the enemy.
I think the only projects that follow any set of guidelines for longer than a few years; they have a narrow purpose for being. Straightforward evolution or needs
