There comes a point where having a few exceptional programmers is no longer enough to deliver a project, so more and more process starts getting wrapped around the software life-cycle to manage the larger team.
Striking a balance between enough process to keep everything on track and allow PMS to make predictions about the project timeline while not stifling your best programmers with a system they end up working against is not an easy task.
If I'm a homebuilder and in my crew I have 5 average-ability builders and one exceptional tile guy, I can't be expected to let the tile guy run the show. I might treat him differently -- give him plans and let him run with them, let him be responsible for meeting his own deadlines and so forth, but in no circumstance can I let that tile guy have total free reign over a home project... and in all honesty, he probably doesn't want it.
I'm not sure the analogy works, but this was my struggle moving from startups to enterprise environments. Personal contribution matters, but there can be no heroes, because the totality of the business is immense. This thinking requires a bit of abstraction on the business side and coming to terms with the fact that you're a member of a team (and there are many other teams all with different relative importance). A cog in the machine? Perhaps, but a startup is just a tiny machine, and when you scale, as is the nature of a successful startup, you do so by adding cogs and thus increasing the size of your machine.
I firmly believe that process doesn't really keep things "on track" as much as it forces the business the choose between competing priorities, and it forces communication. It doesn't matter if it's Agile, XP, whatever -- you need three things for process to work: 1) defined owners with the authority to set priorities, 2) defined intervals when those priorities can't be changed, and 3) agreement between the involved parties that they'll stick to the process.
that's the point - the analogy does not work. A difference in performance between an average worker and an exceptional one is not very large. The difference between an average programmer and a good one can be between having or not having stuff working.
Precisely because of worker analogy, people leave.
Striking a balance between enough process to keep everything on track and allow PMS to make predictions about the project timeline while not stifling your best programmers with a system they end up working against is not an easy task.