You need to understand the mechanism and purpose behind agile. If you don't, then it is just a cargo cult thing. Software development, and product development is one of the hardest things to do right now. You need many independent people working together with "deep unplanned collaboration". How do you do that?
I'm old and I worked at Ingres when they decided to write a new release and everyone went off and worked on it for a year. It was right on schedule. Then they got together to release the product and found that each team had developed a component that failed completely to interoperate with any other components. Have you ever heard of Ingres?
The key to their failure was that they never put the pieces together.
So agile is a bunch of techniques to let people work together on exceedingly complex projects. Calling it agile is indeed just marketing. It is basically a messaging bus. The idea is that those Ingres people could have had some meetings to talk about how their components worked and things would have been better. Maybe not great, but better.
And if those people understood that their goal was to give others insight into how they were doing things, that would have been even better.
But think about this - what if from the very first day they just ran the whole project with all the components? Even if all the functionality was stubbed out, at least they would know that it worked together. We do that now, or we should - continuous integration or whatever.
I knew a person who was a great person and great programmer who had worked in the industry for eight years. And not once had the product they worked been used by another person. Think of all that waste.
So yeah, ignore scrum and agile and all that if you have something better. Its not a religion, its just one way of working together. :-)
> Never integrating the parts until the end has nothing to do with not having used "agile". It's just terrible engineering.
I don't disagree with this exactly, but agile is/can be a useful tool to keep engineering on the rails. It's not like if you do agile, you can forget about engineering practices because you've got agile instead. It just reinforces why good engineering is important, and acts as a stick to keep engineering teams on track. A bit like how with good tests, you just can't get away with sloppy code, because having tests necessitates following best practices.
Yes, true. But this points at the annoying thing about how the agile cult attempts to take over credit for the good engineering practices that all existed before agile became a thing. All agile adds on top is the annoying parts (relentless status meetings, treating developers as faceless interchangeable "resources") that make life worse than it was before.
I am no defender of agile as I have seen it implemented as a cargo cult. So yes, quality engineering can happen without it. However, the communication that can/should/could be provided by agile is required by quality engineering.
My first experience with seeing how effective this communication can be was before agile when a manager held short, goofy meetings once a week and we engineers somehow managed to ship, ship on time, and ship reasonable products.
I'm old and I worked at Ingres when they decided to write a new release and everyone went off and worked on it for a year. It was right on schedule. Then they got together to release the product and found that each team had developed a component that failed completely to interoperate with any other components. Have you ever heard of Ingres?
The key to their failure was that they never put the pieces together.
So agile is a bunch of techniques to let people work together on exceedingly complex projects. Calling it agile is indeed just marketing. It is basically a messaging bus. The idea is that those Ingres people could have had some meetings to talk about how their components worked and things would have been better. Maybe not great, but better.
And if those people understood that their goal was to give others insight into how they were doing things, that would have been even better.
But think about this - what if from the very first day they just ran the whole project with all the components? Even if all the functionality was stubbed out, at least they would know that it worked together. We do that now, or we should - continuous integration or whatever.
I knew a person who was a great person and great programmer who had worked in the industry for eight years. And not once had the product they worked been used by another person. Think of all that waste.
So yeah, ignore scrum and agile and all that if you have something better. Its not a religion, its just one way of working together. :-)