I was extremely fortunate in my choice of companies and work early in my career. I developed in assembly language and microcode and Fortran for a few years. Then, I moved to object oriented languages, primarily at Symbolics, using LISP.
At Symbolics (I left in 1990), we practiced incremental development, iterative planning, and some forms of pair programming. Why? Because the language, LISP, encourages this. It's easy to make small changes. It's easy to take what you have and try something. It's easy to walk someone through small functions and then have that person explain what else you could do. It's easy to grab someone and show them what you have already working, even if other parts don't work yet.
I'm not a LISP expert, certainly not the way I was an assembly language or microcode or Fortran or MAGIC/L expert. I became sufficiently fluent in LISP to write pretty good tests. It took me a long time to get past linear thinking in LISP.
But once I figured out the basics of writing software in LISP, I became a much better project manager. I understood how easy it was to break things into small pieces and write products from the bottom up, rather than the top down. I understood how the engineers needed time to experiment. I could help them timebox their prototype activities. Even though I wasn't a LISP expert, I could use my knowledge of the environment to help the engineers create a product development process that worked.
If you're not happy with your projects, look at the language and environment you use. Maybe LISP isn't the answer for you. But you can create an environment that creates a helpful process — one that allows the technical staff to create small pieces, test them, and build on them. We know that successful software development occurs when we build small pieces from the bottom up and check those pieces with the customers. Make your project environment help your technical staff create successful products.