Agile - SCRUM is used widely now a days.
I say most companies have cowboy coding because their management simply doesn't care about the development process...they just want things done quickly.
Of course the better companies..and the ones you want to work for should have a process in place. I find Agile methodologies & practices such as Scrum, Test Driven Development, Continuous Integration, and Iterative development are most used by these companies.
I've recently taken the challenge of starting at a large organization that has cowboy coding..and i'm introducing agile methodologies to change processes here and improve quality a bit.
I'd say by far the most widely used method is the "make it work now, make it good later" (later as in, either after you no longer work there or the product dies).
Is this the best method? Absolutely not. But you asked for the most widely used one.
Mainly it is Waterfall model.
For process control solutions software people are moving into Iterative processes for developing software like Agile.
I prefer TDD.
Perhaps not what your wanting to hear, but 'Agile' is not a process model but a set of attitudes that can be, for example, used even with Waterfall. A software development process model would be something like eXtreme Programming or Crystal Clear.
The problem is that while the term 'Agile' was created to define a set of attributes (see the agile manifesto) it has been redefined by the community to refer to methodologies. Any methodology (e.g. Scrum or XP) can be implemented as agile or non-agile.
Also, methodologies/processes are aimed at solving different problems. Some provide processes for software developers (e.g. XP mandates pair programming and TDD) while other provide processes for project management (e.g. both Scrum and XP). So comparison is difficult and sometimes meaningless.
To an extent all are waterfall, it just depends on the level of focus.
I recommend reading Alister Cockburn. Different sized teams and different levels of 'criticality' require different solutions. See the Crystal set of processes. Alister has spend almost 20 years studying successful and not so successful teams all over the world. He has found, for example, that in a small team actual process is less relevant that attributes such as frequent delivery.
Hope this helps.
I'm afraid one of the harsh realities of graduation is that 'most' software development takes place in large corporate environments and most corporate IT departments still use a Waterfall (more usually termed at least in the UK) Structured approach to development.
In short that is Design >> Build >> Test >> Deploy >> Maintain
This approach is driven more by the need to manage budgets, delivery, timescales and maintain auditability than develop great software... but hey that's the world we live in...