This is what I would have said. I've only been a software dev for a couple of years, but by far the most important thing I've experienced is buy-in. Every team I've been on that all understands and trusts our process has been significantly more successful and efficient (not to mention more enjoyable as a dev) compared to teams where members don't understand or agree with why we're doing a-b-c or x-y-z.
I think in order to get to that point of buy-in, you NEED the team to be able to say "this isn't working, so let's throw it out and try something new."
To add to this, I always find that making sure everyone understand the 'why' as well as the 'what' makes a world of difference. My favorite project manager would always ask "do you understand why we do this?" when suggesting/introducing new process, and she maintained a good deal of fluidity in our methodology so that we could adjust as needed. One big thing about Agile is quick iteration cycles - build, test, tweak - and I think that applies just as much to process as it does development.
I think in order to get to that point of buy-in, you NEED the team to be able to say "this isn't working, so let's throw it out and try something new."
To add to this, I always find that making sure everyone understand the 'why' as well as the 'what' makes a world of difference. My favorite project manager would always ask "do you understand why we do this?" when suggesting/introducing new process, and she maintained a good deal of fluidity in our methodology so that we could adjust as needed. One big thing about Agile is quick iteration cycles - build, test, tweak - and I think that applies just as much to process as it does development.