I believe that an agile approach is best for projects where the requirements are fuzzy and a lot of interaction is required to help shape the end user's ideas.

However... In my professional work, I keep ending up at companies where an "agile" approach is used as an excuse as to why no effort was put into an up front design; when the requirements are well understood.

I can't help but thinking that if the agile approach wasn't around, I'd be sitting here with a nice high-level specification and not having to revisit the same screen and functionality every second day when something else crops up or so and so hadn't thought of that.

Are the benefits of agile methodologies really enough to outweigh the excuse for being lame it gives to cowboy technical leads?

Update: Ironically I'm now a certified Scrum Master. One of the papers presented on the Scrum course observed that the best development process was one where there was a single expert or guru making the design decisions, however that has obvious weaknesses. Scrum shifts the responsibility for producing quality software to the "Team" which means a sub-standard team can get away with churning out spaghetti which I guess is no different to other Agile and non-Agile development processes.

  • 6
    Downvotes eh... I do find some agile converts get be a little bit defensive especially when they see agile and cowboy in the same sentence. And I'm not even bagging agile it's the cowboys that irritate me.
    – sipsorcery
    Commented Oct 12, 2010 at 5:38
  • 2
    This might have something to do with why many of the original signatories to the Agile Manifesto are expressing distaste for the term "agile" as it is used in most companies. Instead, they're now talking about things like "software craftsmanship." Commented Oct 12, 2010 at 15:17
  • 1
    First, let me say that I am NOT a fan of agile. Second, I'll say that in my experience, "capital A Agile" just slows everyone down (including cowboys). I haven't ever worked in a situation where I felt that agile was enabling the so called "cowboy coder".
    – TM.
    Commented Oct 12, 2010 at 16:32
  • 1
    I don't think it's accurate to call what you are describing "cowboy coding". This isn't an individual problem - it's a group problem. This is poor product and team management.
    – matt b
    Commented Oct 13, 2010 at 1:19
  • 3
    I find thinking up front to be almost pointless. Iterating toward a solution following first instincts can be very effective, if you employ sensible programming practices. My experience indicates that those who lay substantial plans up front cannot react to reality once they start programming. Commented Oct 13, 2010 at 15:36

16 Answers 16


I'm Glad it has a name

I believe if you're using Agile development as an excuse for cowboy-style programming, then you're not really following Agile development. Cowboys will always be cowboys, no matter what process you give them.

  • 17
    Dilbert (always) rocks.. Commented Oct 12, 2010 at 16:23

Agile is no more to blame for poor development practices than BDUF. The problem lies with the discipline, or lack thereof, in applying the practices. The purpose of BDUF practices is to identify the direction of the project and determine risks beforehand. The purpose of agile practices is to keep the state of the development flexible enough to quickly change direction. An agile project could prepare highly-detailed user stories so the team is aware of future directions and still only select 2 or 3 per iteration to fully implement. The problem remains the same whichever methodology is used: management is letting cowboys run amuck.

[BDUF: Big Design Up Front]

  • 3
    It will never be possible to thwart the cowboys no matter what the approach. However at least with waterfall they would have to at least produce a requirements doc, a sepcification doc etc. With agile they can essentially get away with just banging straight into the code.
    – sipsorcery
    Commented Oct 12, 2010 at 5:08
  • 3
    Again, this is a failure to manage the process properly. The customer should be educating the developers as to what the business value is in the user story, and the tests should verify they're integrated into the codebase. Log the areas where developers are having to retrace their steps. Are they not well-versed in the customer's business process? Are they uncertain as to the deployment environment? If the project is incurring extra development cost due to "component rework", management should want to correct that to reduce likelihood of going over-budget or schedule. Commented Oct 12, 2010 at 5:30
  • 4
    If you just start banging away at code you are not doing agile even if you call it so. What is to stop me just banging away at code and calling it waterfall if i spent 5 minutes thinking about requirements at the start.
    – Craig
    Commented Oct 12, 2010 at 5:35
  • 1
    Huperniketes has it right, the problem is not with the methodology; the problem is with the management team letting the cowboys run the department.
    – Jeff Siver
    Commented Oct 12, 2010 at 5:40
  • 7
    @sipwiz: Even in waterfall, cowboys would bang straight into code. Eventually they'd document whatever they wrote as the design spec.
    – TMN
    Commented Oct 12, 2010 at 12:31

Oddly enough, from the "agile" projects I've been involved with, it seems more like a management excuse to skip the requirements-gathering phase than a cowboy desire to simply start coding. My projects have been extremely frustrating because we don't have any end-users to interact with. Instead, we have a director who talks to sales to find out what they think customers want, then calls a meeting and describes it to the managers, who then start assigning tasks to developers. On a "good" project we might have a PP presentation to refer to, but usually we wind up spending our daily scrum meetings asking how some feature's supposed to work, and the manager writes down the questions and asks the director. It's a huge waste of time -- but it's "agile"!

  • We don't call it anything, but this is basically how things go around here. We actually have some big design docs, but they're out-dated and no one looks at them. Instead every new feature or fix is dictated solely by what the VP thinks is hot or what sales is saying customers wants, hashed out quickly in meetings, and thrown down under heavy deadlines. Commented Oct 12, 2010 at 15:52
  • +1: @TMN, @CodexArcanum: I also had the same experience. There was no user champion. Sales dictated new features to product management, who then passed them on to development.
    – Jim G.
    Commented May 9, 2011 at 11:49

Agile, like anything, can be used to cover a bad behavior or to try to solve a problem that the team think they are not responsible of.

However, the magic in some Agile methodologies like Scrum is that they will provide lot visibility on problems within the organization. Including problems within the team!

You will be then given the opportunity to solve them as they arise.

If the problem lies to the cowboys, this will be very visible after the first iteration. If the problem is elsewhere, you will see it very soon too.


I will not say that I am a fan of Waterfall, since I too deal with ever-frustrating scope-creep, but I have always seen Agile as a concession to the problem, not an effective way to combat it. A good design, with early iterative testing and lots of paper prototypes seems to be much more effective.

  • 5
    The problem is a good design is next to impossible for anything other than trivial projects. Issues with the design only become apparent as the project progresses. Users don't know what they want no matter how expert they are.
    – Craig
    Commented Oct 12, 2010 at 5:38
  • @Craig. While I agree with you that specs are next to impossible to nail down, even non-trivial systems should be able to be prototyped on paper and this is a whole lot cheaper to do than actually writing the entire system only to find that it needs to be rewritten. If it cannot be paper prototyped (at least for basic functionality), it is difficult to imagine that the particular system will work well or be reasonable to implement in the end anyway. If you and the user cannot sit down and walk through a test scenario on paper before you start working, then there will be serious problems.
    – user3792
    Commented Oct 12, 2010 at 6:34
  • 2
    @Craig I'd disagree that a good design is impossible. Knowing every single intricacy of the system up front may well be near impossible but it doesn't mean a design against what's known can't be produced. I mean even a single sentence along the lines of "This app will be written as an MVC app using the entity framework for teh DAL" would be something. Apart from that I've seen tenders where there are 180+ pages of requirements and you can't tell me that's not enough detail to produce a pretty good design.
    – sipsorcery
    Commented Oct 12, 2010 at 11:09
  • sipwiz, my experience is that number of pages does not correlate to the usefulness of a spec. What is written is more important, not how much. It totally depends on the system whether 180 pages is good or not, if I am building Windows I would think it is a bit light on.
    – Craig
    Commented Oct 12, 2010 at 11:35
  • 3
    Also I think you need to remember, agile does not mean no spec.
    – Craig
    Commented Oct 12, 2010 at 11:53

I am seeing defenses of Agile Development saying that it is not responsible for failures caused by cowboys. Success with Agile requires diligence and intelligence.

This seems a reasonable position, as long as you apply the same concession to other methodologies. If you can't blame Agile for project failures caused by cowboys, you can't blame non-Agile methodologies for project failures caused by cowboys.

We can then argue whether there is a correlation (not causation!) between Agile and cowboys. With only anecdotal evidence, I believe there is. Is it perceived as a good way to get by with cowboy practices without being detected by management?

Of course, if we accept that cowboys may not be evenly spread across methodologies, and we accept that cowboys undermine the successful use of a process, we have made it very difficult to test whether a process is successful. The claim that one process is better (within a context) becomes close to unfalsifiable. This is one of the issues that makes me hang my head in shame about my profession - the lack of scientific underpinning of many of the claims.

(By the way, I hate calling the alternative(s) to Agile "waterfall", because waterfall processes seems to be a strawman that everyone attacks, but very few people ever actually used without any iteration.)

  • 4
    Development failures aren't the result of cowboys being present. Development failures are the result of management not being present. Commented Oct 12, 2010 at 16:18
  • @Huperniketes, that is FANTASTIC news. Programmers are never to blame! What an ideal profession we have chosen! Commented Oct 13, 2010 at 0:25
  • @Oddthinking, stop limiting yourself to binary thinking. Programmers can certainly be blamed for failing to perform to the level of their profession, but programmers are never to blame for project failures. That's the responsibility of project managers. Commented Oct 13, 2010 at 2:29
  • @Huperniketes, perhaps you could clarify further, please? You originally said "development failures", but then moved to "project failures". I agree that project managers may have to "carry the can" if one of their developers performs below expectations, but it is hard to see how cowboys failing to deliver can never be the cause of a project failing. Commented Oct 18, 2010 at 5:45
  • @Oddthinking, I meant no distinction between "development failures" and "project failures". They're used synonymously here. Sure, a project might not have succeeded because the programming effort was sub-par, but the project manager's duty is to identify those cases and remedy them with changes to the team when needed. It's his job to see that the project succeeds. He needs to be fired if he can't do that. So he needs to ensure team members, even cowboy coders and rock star programmers, are fulfilling their obligations to the project or fire them. Commented Oct 18, 2010 at 9:09

Agile is fine as long as it is working for your team.

Far too many are selling it as a way to turn a bad team into a good team, and it just doesn't work that way. You can't take bad people and apply a process to suddenly make them useful.

I like many of the ideas behind agile, but the failure I see time and time again is that the managers are pushing a strict set of "agile processes", which flies in the face of the entire concept of agile, that teams should be self-organizing.

As far as "cowboys", I find that for all the agile teams I've been on, the processes serve to slow them down more than let them go wild. I've never experienced a situation where agile served to enable a "cowboy coder".

For good teams, it seems to work well (then again, most processes seem to work well when you have a good team, funny how that works isn't it?).

For other teams, in my experience, it never helps the bad people do better, but it sometimes serves to bog down the productive people.

Overall, I think the important thing is to build a good team, tell them what you need, and then get out of the way. I don't think applying any string of buzzwords is likely to solve the problem of having a bad team.

(If you haven't figured out from the above, I'm not a fan of "Capitol-A Agile" in the least. On the other hand, I don't think it encourages cowboys either.)


Agile when done properly should have the effect of reining in "cowboy" technical leads and "hero" programmers. If you don't observe this effect, that may be a sign that something important is missing from your agile implementation.

I want to add that "Agile" is really an interface (I'm using an object-oriented metaphor here) and you cannot instantiate it. If your concrete implementation of it is XP, then you have to follow a bunch of technical practices with a lot of discipline, which leaves little room for cowboy programming. Another possibility is that the teamwork of a well-self-organized Scrum team will keep it in check.


Cowboy coders also tend to write code that is not very testable, and they tend to not like writing tests. I think having everyone doing TDD can help reign in the cowboy attitude and make developers think about architecture a little more. No methodology is perfect, of course.

  • 1
    Don't forget the paranoid "if (var != null)" checks sprinkled all over the code... Commented Mar 30, 2015 at 14:24

I'm currently working in a shop where this is the case, except it's more to do with organisational culture than with particular individual cowboys.

The organisation has always operated on a relatively loose, "informal Agile" approach. I wouldn't say it's truly Agile, it's more "Agile in name", but just plain non-existent methodology in practice. Different teams operate differently, but since the overall organisational culture doesn't have any methodology in place other than a very loose "Agile in name only" process - it's relatively cowboyish and chaotic overall - especially in intergration (and there is a lot of that).

The moral of the story is - Yes, this does happen. If I was job hunting at the moment, I would be very careful with this. If a shop is claiming to be Agile - I'd ask some pretty tough questions in the interview to ensure that more than just a misnomer of Agile is actually being followed.

  • 1
    That sounds very like my situation as well. And it gets to the point of this whole question in that if "Agile" wasn't around organisations would probably stick to waterfall and whatever its shortcomings it's far far superior to having no process.
    – sipsorcery
    Commented Oct 12, 2010 at 22:50

I found that users can only give us feedback once they have an application they can use, screens they can enter data on. Only then, they truly understand what we were trying to say in the requirements documents (that clients sign but everybody have its own version of the meaning). If it is not an agile development, it is going to be a waterfall project going over budget but the application is going to change once you deliver it. Your first version is no more than a prototype for users to discuss what the requirements should have been. So I rather call it agile than over budget.

  • I've seen this, too (customers who see an early version and get too caught up in the bugs/features you know aren't ready yet), and you can sometime struggle to get useful feedback. I think this is a matter of educating your customers, though. Commented Oct 13, 2010 at 8:26
  • Prototyping....
    – sipsorcery
    Commented Oct 13, 2010 at 9:35

I think its true, in some environments Agile is used as an excuse for no discipline. The real problem is we've lost sight of why we have any methodology. Personally, I feel the methodology is an architectural issue in the sense that the architecture of the system is supposed to address the non-functional, quality attributes, the methodology should be addressing some of those same attributes (maintainability, development productivity, knowledge transfer, et al.)

Viewing the methodology as a control for the process attributes implies a couple of things: 1) without metrics we cannot compare the effectiveness of one methodology over another, 2) an active decision needs to be made about what attributes are important (delivery time vs code quality vs knowledge transfer).

Without having both metrics and a tangible goal, we simply choose a methodology as our "magic feather" that if we hold on to tight, we'll be able to deliver software.

Now the nay-sayers of Agile, XP, Scrum, etc talk about the fragility of that particular category of methodologies. The argument being: why use a methodology that can be sabotaged by one individual lacking the discipline to follow all the rules? The question is a valid one; however, that is the symptom, not the cause. If an accurate and meaningful (that's the hard part) set of process metrics are defined, tested, and timely feedback given I think we'll discover the particular methodology has little to do with success. (Anecdotally speaking I've seen successful projects using a myriad of methodologies and twice as many fail using the same methodologies)

So what are the metrics? They vary from project to project, team to team, and time to time. Useful for when the delivery schedule is important, one that I've personally used is estimation skill and quality. Most developers can accurately estimate tasks that are a week long or less. So one approach is to divide up the project into tasks one developer-week long and track who made the estimation. As the project goes along, they may change their estimates. After a task is complete, if its off by more than 10% (1/2 a day) we treat this the same as a bug - we identify why the estimate was off (i.e. a database table wasn't considered), identify the corrective action (i.e. involve the DBA in the estimation), and then move on. Using this information we can create metrics such as # of estimation bugs per week, # of bugs per developer, # of bugs per KLOC, # of bugs per developer-KLOC, etc. Posting these numbers on the team wiki provides serious social pressure and from the managerial perspective, after a couple of weeks, you can generate a predictive model of subsequent development weeks.

So what? That's when the methodologies come in - if you have a predictive model that fails to meet the process qualities, you can choose to add or remove some aspect of the methodology and see how it affects your model. Granted, no one wants to play with a development process for fear of failure, but we're already failing at a consistently high and predictable rate. By making individual changes and measuring the result you may find that Agile is the perfect methodology for your team, but you could just as easily find RUP, waterfall, or just a hodge-podge of best practices to be ideal.

So my suggestion is lets stop worrying about what we call the process, put in place checks that are relevant to our development process goals, and experiment with different techniques to improve that process.

  • Good points. My frustrations stem from the deliverables in an Agile approach are much more fluid and that allows an incompetent tech lead to get away with anything they want and which in my experience ends up as no process at all == cowboy coding.
    – sipsorcery
    Commented Oct 27, 2010 at 22:17

I'd be sitting here with a nice high level specification and not having to revisit the same screen and functionality every second day as something else crops up or so and so hadn't thought of that.

That does seem to tally with my colleague's experience of the "agile" project he is on (I've never been on one myself): he is asked to write a piece of code to some spec, then just as he's finished testing it and is ready to move on a new requirement comes up that requires him to change it and re-test it. He finds it frustrating.

I'm not bashing agile, I suspect the team is not doing agile properly - but as you say, the term "agile" can sometimes be used by cowboys to convince pointy headed management that half-baked design is a positive rather than a negative.

  • agile without automated tests is asking for headaches Commented Oct 12, 2010 at 18:54

Its funny how nobody thinks of themselves as cowboy coders. Im betting many of the posters are or have been one ;)

  • 1
    I'd suspect most of us started as cowboys. Commented Oct 27, 2010 at 21:26
  • You may be right, and I haven't been programming long, but when I was at a shop with no methodology, we had cowboys. I'm at an agile consulting firm now, and what you do is big and visible, and it is actually hard for me to imagine a cowboy coding enjoying this environment. Commented Nov 9, 2010 at 2:58

Cowboy coders are good because they like getting stuff done quickly. They often are not as concerned about big-picture issues or code quality, which is why "cowboy coder" is often an epithet. Their methods mitigate the opportunity cost risks of late project delivery.

Non-cowboy coders like doing their work in a safe, disciplined, and orderly way. They like building it right and building it once. They are known for forever gathering information, considering what-ifs, producing large documents which nobody reads, and delivering systems late or very late. Their methods try to mitigate the risks of poor quality software.

The brilliance of Agile methodologies is that they harness the strengths of both types of coders by forcing short time-bounded working iterations which ask coders to produce small high-quality pieces of work quickly. And each iteration mitigates both the opportunity cost risks of late delivery and the risks of poor quality software.


The reason while agile is putting very little emphasize on up-front design/specifications is not just because requirements may change. The deeper reason is that even when requirements are stable, specs tend to be:

  • incorrect - fail to capture the requirements.

  • inconsistent - riddled with contradictions because they contain enough information to make it impossible to the writer/reader to catch them.

  • detached - they do not incorporate valuable feedback from a running (although degenerated) system.

Not the answer you're looking for? Browse other questions tagged or ask your own question.