[orangeshark]

I don't really have that much industry experience but have been reading a lot about development processes and practices. It seems there just isn't one development process that will solve all your problems and allow you always create successful software. To me it seems you just need to find what works for your team and continuously work on improving on it. What might work today, probably won't work for your team tomorrow so you need to always look at how can you improve your process.

ACM recently had a series of webinars[0] by Ivar Jacobson on Essence[1]. Essence was kind of confusing at first, but it is essentially a language to describe practices from the different processes. The idea is that you can build up a library of the various practices in your company and allow teams to pick their own and evolve their process by swapping out practices that just don't work out. Essence seems like an interesting idea, especially if it allows teams to create a development process that fits them.

[0]: https://www.sigsoft.org/resources/webinars.html

[1]: https://www.ivarjacobson.com/services/what-essence

[Const-me]

I have decades of industry experience and I mostly agree.

> find what works for your team

For the combination of team and project. Different software projects need to take very different tradeoffs in how they managed. Use scrum in aerospace for flight control, and people will die. Use scrum for system software, and you'll have hard time delivering quality and performance, system software often requires non-trivial amount of engineering. Implement NASA's best practices when working on videogame or web app, and you'll blow budget.

This article is from 2002 but still good: https://www.joelonsoftware.com/2002/05/06/five-worlds/

[jon-wood]

You may not have much industry experience, but you’ve managed to hit the core of the problem. There is no one process that will work for every team, or even every project.

Every team at my workplace runs a different process. We’ve got a team developing new features who are running an iterative agile process, allowing them to react to changes ok requirements or unexpected issues with as little disruption as possible. We’ve also got a team doing B2B projects, essentially rebranding our mobile apps and platform for different companies, and that’s pretty traditional waterfall - I wouldn’t in a million years use waterfall for new features, but when you’re running through a set of well understood tasks that need delivering on schedule to coincide with work by third parties it gets the job done.