Is the agile approach too much of a convenient excuse for cowboys

Question

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.

Answer 1

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.

Answer 2

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]

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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

Answer 15

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.

Answer 16

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.