The manifesto for agile software developement brought forward so much positive change to the industry but when developers misinterpret it they can take some of the principles too far. Doing this creates a cowboy developer. See the cowboy manifesto

Agile Dev Cowboy Dev
Individuals and interactions over processes and tools:
Teams define the processes and tools which work best for them, and they may change it in the future but there are guidelines in place which keeps everyone in the team on the same page.
Individuals and interactions with NO processes and tools:
Without processes and tools in place the cowboy dev can do what he wants, when he wants. "Dev straight on production branch?"... No problem. "Take a POC to production without any tests"... No problem.
Working software over comprehensive documentation:
Documentation allows for team members to quickly and easily understand the system as a whole or detailed complex parts of a system. Documentation is especially important for junior devs, new devs or devs revisting old code.
Working software with NO documentation:
When shooting from the hip theres no time for documentation. Regardless... the cowboy knows what he is doing and nobody else needs to know.
Customer collaboration over contract negotiation:
Time equals money when paying a team of software developers to build your project. A software team cannot make endless changes without getting paid and the customer does not have the money to pay for unlimited changes. As much as the customer needs to be part of the whole process, somebody has to take time and money into consideration.
Customer collaboration with NO contract negotiation:
The cowboy gets paid his salary either way and has no reason to worry about costs. Cowboys like to collaborativly convince the customer of some new tech because the cowboy wants to play with the tech or do something interesting instead of useful. Finacial repercussions from "lost dev time", "slow to market products" and "future support" is not a concern for the cowboy.
Responding to change over following a plan:
Planning should be part of the agile process, with many small planning sessions instead of one big planning session in the beginning. Having designs and plans in place can actually make the project more agile, see Agile Vs Design to see how. Basically good design should make it easier for developers to respond to change.
Responding to change but have NO plan:
The cowboy responds to evey problem which comes his way as it comes, so he doesn't need a plan. Nobody can tell the future anyway... so why plan???