There are all kinds of software development processes out in the world today. I can confidently say that the two most well known are Agile and Waterfall. Early on in a programmer's career, they're indoctrinated to believe the Agile methodology is the key to better and faster products. There can be a lot of different explanations for what an Agile software process is, but the most familiar and widely boasted benefit for using it is the ability to create a quick feedback loop between the project stakeholder and the programmer.
Software development processes all boil down to the same goal: you have list of negotiated features you need to implement in your program and you release your project based upon those expectations. But different processes kind of muddy the waters of what those expectations mean and how they are managed and dealt with. This leads to more confusion and unmanaged expectations between the programmer and the product stakeholder, and ultimately more rules around your software development process.
I get a little unenthusiastic about programming once I have to pour more and more time into following the strict rules of how to communicate, estimate, test, document, and deliver software. I have also worked with many people that have been even more opposed to this sort of project management than me. However, there is one thing I have to remind myself of when I start noticing software development processes breaking down or getting more and more strict:
"Process isn't about a set of rules to adhere to. It's about open and ongoing communication within your team."
I think a lot of these issues in software development can be fixed with more communication among all team members. I guess my next goal is to step back a little bit and figure out how to facilitate more dialogues rather than more items to a checklist. I'll let you know how it goes.