Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
4  
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. –  sipwiz Oct 12 '10 at 5:38
1  
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." –  Darcy Casselman Oct 12 '10 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. Oct 12 '10 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 Oct 13 '10 at 1:19
2  
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. –  dash-tom-bang Oct 13 '10 at 15:36
show 3 more comments

17 Answers

up vote 74 down vote accepted

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.

share|improve this answer
15  
Dilbert (always) rocks.. –  TheVillageIdiot Oct 12 '10 at 16:23
add comment

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]

share|improve this answer
2  
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. –  sipwiz Oct 12 '10 at 5:08
2  
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. –  Huperniketes Oct 12 '10 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 Oct 12 '10 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 Oct 12 '10 at 5:40
6  
@sipwiz: Even in waterfall, cowboys would bang straight into code. Eventually they'd document whatever they wrote as the design spec. –  TMN Oct 12 '10 at 12:31
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
show 2 more comments

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.

share|improve this answer
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. –  sipwiz Oct 12 '10 at 22:50
add comment

Cowboys in an agile environment will start to miss their own estimates.

share|improve this answer
add comment

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

share|improve this answer
show 2 more comments

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.)

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.)

share|improve this answer
3  
Development failures aren't the result of cowboys being present. Development failures are the result of management not being present. –  Huperniketes Oct 12 '10 at 16:18
show 7 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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"!

share|improve this answer
show 2 more comments

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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
3  
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 Oct 12 '10 at 5:38
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. –  sipwiz Oct 12 '10 at 11:09
3  
Also I think you need to remember, agile does not mean no spec. –  Craig Oct 12 '10 at 11:53
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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