John Fuex has been working in software development professionally for over 15 years in Austin, Texas. Although he still keeps his hands dirty in code as much as possible, he has spent most of the last decade managing software development teams for a litigation services company. His passions are software development process improvement and mentoring aspiring novice programmers. John is a DZone MVB and is not an employee of DZone and has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

Is Agile for Amateurs?

  • submit to reddit

I found myself discussing development practices with a manager of a local startup software company and was a little taken aback when he unequivocally proclaimed that they didn’t need agile because he had a team that consisted solely of extremely talented veteran programmers, with an average tenure of more than a decade.

He claimed they knew what needed to be done and did it without any official methodology. In these parts we might call that “Cowboy Coding.” His premise that following a standard methodology was meant for novice teams or those with immature programmers who hadn’t gotten “into the groove” of their careers.


Before you trash the guy,  consider the following:

  • The guy and his team really were hardcore. It was chock full of developers that I’d love to be able to lure over to my shop.
  • This guy had bootstrapped several start-up organizations and is extremely technically competent for a suit.
  • He based this statement on demonstrable results, working software that apparently was popular with his customers.

How can you argue with results? Of course, I’m not absolutely sure about the veracity of his claims of success. In the context of our conversation it was conceivable he might have been exaggerating given that I currently work for a company that is a potential customer for his company’s product.

Personally, and despite these points I still tend to disagree. Even though he may be seeing success despite an unstructured development environment. I’d argue that the team may still be performing below their full potential and would still benefit from some flavor of an Agile approach.

It seems to me that Agile is better suited to teams with a lot of talent and experience, and if anything would be more problematic with a bunch of rookies. A core Agile concept is to let the development team self-organize, which implies a great deal of trust.  Agile is not about babysitting, and certainly not about command-and-control management. It is about communication, coordination, and frequent re-alignment with an emerging picture of the customer’s needs.

I’m curious what you guys think?



Published at DZone with permission of John Fuex, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Lieven Doclo replied on Fri, 2011/07/15 - 12:33am

The only times I seen an agile approach fail is when you're either dealing with a team that is 100% committed to proving that an agile approach won't work, or when you've got a rock star team with rock star ego's (the second case almost always implies the first). Agile makes development very, very transparent, something that some developers really don't like. It's harder to hide your incompetence or the fact that you really lack social skills (hence the resilience of the first group) and you can't really do stuff under the radar, introduce stuff without anyone noticing or just do stuff because 'they're all idiots' (hence the resilience of the second group). Veteran cowboy coders with an ego the size of Texas fall in that second category. They're probably real technical geniuses, but you won't see them working in agile teams, that's for sure. It's just a personality thing that just won't mix with agile approaches.

That said, agile works for both veteran coders and rookies. Veteran coders can get a lot more done with an Agile approach as impediments don't linger for too long. From my experience, it's easier to get in a groove with an agile approach. Rookies get a lot of information out of the fact that the entire process is so transparent. Technical information sharing is part of the development methodology.

But Agile isn't for all companies. If they can't handle the explicit transparency (stand-up meetings, frequent reviews) or don't want to commit any time for the development process, they'll probably fail. If the company is committed to using agile (the real deal, and not the buzzword kind) and is willing to invest time in an methodology which is aimed at improving internal development directly and external customer relationship indirectly, they will succeed. But chances are not all of it's developers will cross that finish line and you may lose a couple of people you'd rather not have lost.

Jilles Van Gurp replied on Fri, 2011/07/15 - 12:40am

I think agile often creates an illusion of professionality that can lead people to collectively believe that they are doing pretty OK and have reason to be proud of themselves while in fact they are progressing at a snail pace putting together bog standard database applications. The sad reality in our industry is that a single excellent developer can outpace the productivity of an entire team of average programmers. It's not a myth and it has absolutely nothing to do with methodology or best practices. Software engineering continues to be a skill based profession where most of the skill is acquired through experience, apprenticeship, and intelligence after you leave college. Put a few smart and productive developers together and they will start building stuff almost immediately. Most of them do it in their free time as well. If you have such people around, trying to not slow them down, annoy, or alienate them is a pretty decent business strategy.

Most open source projects are run by such people and some excellent software is coming out of there. OSS and Agile are almost completely separate worlds. The OSS world is full of one man projects and accidental collaborations of a few individuals. They tend to organize as loosely as they can get away with: no sprints, no product owners, no backlogs, no stickies on a wall, none of it. Of course quality varies wildly as well and there tends to be some natural selection there where mediocre stuff simply doesn't survive very long while the good stuff tends to gain popularity and community.

Mediocre teams often need a lot of time to grasp requirements and to translate their poor grasp of the domain into sensible action. Something that is immediately obvious to a skilled engineer might take a room full of junior developers weeks to wrap their heads around. Agile is basically about smoothing this process and it introduces a lot of checks and balances based on the empirical notion that most mediocre programmers do a pretty shoddy job if left to themselves. That's good because it allows you to get stuff done with reasonable amounts of resources. Rock star programmers don't grow on trees and most businesses have to deal with the reality that the vast amount of their work force is not able to operate independently in a meaningful way. Agile is there to facilitate people working together more effectively and it sort of works well for a some people.

However, if you are a startup and your staff is mediocre, you are going to fail no matter how good your process is. That's why most successful startups start out small with a handful of really good people that generally don't need a lot of ritual and guidance to get going. Provide cash, pizza and cafienated beverages and they'll do the rest. That only gets you so far of course.

There seems to be a lot of dogma and myths surrounding agile. It's almost like mass hysteria. I've seen rooms of engineers citing success stories to each other that wouldn't survive the scrutiny in a decent peer reviewed scientific publication. Just because a lot of people believed the world was flat in the 15th century didn't mean they were right. Just because a lot of engineers have convinced themselves that scrum is the best thing since sliced bread doesn't mean it is.

Don't get me wrong, I have nothing about the pragmatic application of what are essentially sensible practices but what passes for methodology in the agile community is in my view 95% completely baseless empirically unfounded bullshit. And having a background in doing software engineering related research, my bullshit detector tends to be pretty good.

I've seen more than a few scrum and agile deployments go spectacularly wrong. You never read about such projects but they are all over our industry. You probably worked on several as well. The success stories always are about a team of developers in need of change and invariably they are coached to success by a lone cowboy agilist from a respectable consulting company that came in and save the day. We refer to that as seagull management where I work. Somebody comes in, shits all over the place and flies away before he can be held accountable. We've had a few bad cases of our management drinking to much of the coolaid and spending tons of money on consulting.

Ultimately, you need good people and you can't fix the fact that you don't have them by pretending to be agile.

Nico Mommaerts replied on Fri, 2011/07/15 - 12:57am

When I started out in this field some 10 years ago I was a real agile fanboy. My last agile project (incl 100% pair programming, scrum, all the post-its etc etc) was 2 years ago. Now I can't agree more with what Jilles says, couldn't have said it better.

Roger Lindsjö replied on Fri, 2011/07/15 - 2:12am

To me it seems as you are describing an agile process. "they knew what needed to be done and did it" sounds that the developers themselves had a prioritized backlog that was updated continuously. Sure, the might not have had a formal owner of the backlog, not "sprints" and maybe no need to visualize progress with whiteboards or fancy collaborating tools. Compare that to a non agile process where what features and when and how to develop them is decided month or even years ahead of time and then sticking to that plan at any cost.

Andrew McVeigh replied on Fri, 2011/07/15 - 5:06am

> I think agile often creates an illusion of professionality that can lead people to collectively
> believe that they are doing pretty OK and have reason to be proud of themselves while in
> fact they are progressing at a snail pace...

very well written jilles. i've seen this a number of times now. processes themselves are never fully the answer, the people involved need to respect the intent of the process and be (objectively) delivery focussed.

Matthew Welch replied on Fri, 2011/07/15 - 8:52am

I think agile often creates an illusion of professionality that can lead people to collectively believe that they are doing pretty OK and have reason to be proud of themselves while in fact they are progressing at a snail pace putting together bog standard database applications

I couldn't agree more. I'm not against agile. The best job I've ever had was done using a very agile approach, although that's not what we called it at the time. It was just our natural way to work on a very small team of extremely bright people. More recently I've seen agile applied as a rulebook that guides a rigid process for a middle of the road and much larger team. The development progress of the application has slowed to a snail's pace over the last two years, buy hey, at least we're agile! Right?!?

People matter. So many businesses repeat that to themselves and spout it as a mantra but their actions just don't match their words. People are SO much more important than process that it's not even funny, but businesses think they can overcome average people with a great process. It's a joke.

David Clark replied on Fri, 2011/07/15 - 6:27pm

I’m not much of a fan of agile myself, but I believe in process as part of software development. I think the real sentiment being expressed is that experience trumps process. Maybe that is an appropriate cost/benefit tradeoff in this case. But it is certainly not appropriate in all cases. It’s really a statement that failure of your system is essentially inconsequential.

Consider an airline pilot. They have gone through the process of flying a plane from one point to another hundreds of more times than you have started new development projects. Yet they go through the process of filing flight plans, the pre-flight checklist, and all of the other steps of assuring a successful, safe flight. Would you want them to act differently? No, because the consequences of a failure could be catastrophic.

My personal heroes in the area of software development are the Shuttle Flight Software development team. They write software that never fails. And they do it over and over. There are no super rock-star ninja code cowboys on this team. They achieve that performance by strictly following a well-defined, detailed process.

Nobody really cares if your social network clone crashes every so often. But if you write software that does something difficult and important, like controlling the braking system in a car, controlling a medical device with the potential to blind you, interprets medical information where an error could injure or kill a patient or cause an unwarranted abortion, or software that launches a space shuttle, you want every possible advantage you can get. A good development process contributes to those advantages.

Lund Wolfe replied on Sat, 2011/07/16 - 1:29pm

If this startup/hiring manager is sufficiently open minded, confident, and competent with a history of success, then power to him. Just because he isn't hiring for or using a specific methodology, doesn't mean his team isn't following best practices and cooperating in a manner best suited to that team and that kind of application. Just because they're gurus doesn't mean they're doing "cowboy" development with no professionalism or risk management. Truly talented developers can work together and can compromise when necessary.

What you definitely want to avoid is the shop with one know-it-all (jack of all trades) indispensable developer and a horde of basically unskilled programmers (following a process or not).

Claude Lalyre replied on Fri, 2011/08/19 - 8:31am

Whell written Jilles ! You make me laughing a lot with your expressions ! I think some day, some one should make a movie on Developers community and their carrier managment. It was really funny !

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.