That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour
"having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.
Here is another perfect examplee of what's wrong with SCRUM, it creates zealots. When someone starts talking about a need to give good, self-disciplined devs a little freedom instead of micromanaging them to death the scrum zombies start shouting about "cowboy programmers". When someone starts talking about long-term or strategic planning they start screaming about "waterfall".
The truth is that there is a lot of evidence from the field that having good developers and zero formal process is actually fairly workable, and often produces results. It's typically not the best system, but it's a strong antidote to the poisonous ideas of SCRUM, which holds that constant micromanaging at every level is strictly necessary otherwise puppies will die.
There are good elements within agile, such as iterative development, continuous integration, etc. but if you just choke down a whole ideology without exercising any degree of critical thought then you're going to make a lot of people miserable.
Good developers+zero formal process only works to a certain scale, though. I think that's where scrum might have a place, just enough process to keep things from going off the rails when the team is too big to self-organize over a long period of time.
Agree about the danger of zealotry though. Also, the vocabulary is just so ridiculous - I have to mentally think "black dog grooming" when I say "backlog grooming" just to keep my self-respect.
It also depends on the nature of the work. Is it more mechanical, a more-or-less straightforward implementation of a spec? Or does it require real creativity, invention, non-linear thinking? Anyone who truly understands the creative process knows you have to give it freedom.
Scrum might have valuable in big hierarchical companies or when there are many average-talent programmers, but there's no way I'd foist it on a team of smart developers much less and early stage startup.
Scrum is pretty much exactly the opposite of what you apparently think it is. Is is ALL ABOUT giving the developers freedom and and inteded exactly for projects that require creativity and don't have a spect to implement straightforwardly.
The truth is that there is a lot of evidence from the field that having good developers and zero formal process is actually fairly workable, and often produces results.
It's typically not the best system, but it's a strong antidote to the poisonous ideas of SCRUM, which holds that constant micromanaging at every level is strictly necessary otherwise puppies will die.
If you've got a team claiming their doing Scrum where you see constant micromanaging - that team is not doing Scrum. At the very core of Scrum is the idea that the team organise their own work (within the very few practices that Scrum enforces).
(Obniggle: Scrum is not an acronym you don't need to SHOUT :-)
You obviously have no idea whatsoever what you are talking about. Please actually do some reading about what SCRUM is before you spread this kind of FUD.
I completely disagree [1]. There's a difference between a cowboy programmer and a programmer that can go more than a day or two without checking in with his superior. In my personal opinion, based on the level of intelligence required to do good programming, the best programmers are self-managing.
As a corollary to that, it's too expensive to hire development managers (in the traditional "management" sense) that can actually add value. Good programmers are that good.
[1] I've fired every cowboy coder that ever worked for me except one.
Actually, you completely agree with me. A Scrum Team very explicitly is self-managing. Agile processes ARE frameworks for coordinating self-management at the team level, and which have been found to work repeatably. That doesn't mean a given one will work everywhere. Specifically, Scrum is probably not ideal for startups doing something truly new, since it assumes there is someone who can prioritize features by their business value.
Why would you tell somebody that they completely agree with you when they just said that they disagreed? That's so rude. You say "That's cowboy programmer bullshit", he says "I completely disagree." Do you really think there's a chance he secretly agrees that his view is "cowboy programmer bullshit"?
In Scrum, superiors check in once per sprint at the end of one / beginning of next, unless they want to change priorities (not plans, priorities) for the team and cancel previously requestd delverables.
Isn't that just a No True Scotsman argument? You're saying that Agile is good because it's isomorphic to any successful, minimal ad hoc process that fits the project. Well, OK, if that's your defintion of "Agile".
But the "Agile" (rather "Scrum") described in books and web videos and blog posts isn't like that at all. It has become a decidedly "heavy" process with all sorts of jargon behind it. My guess is that this is what the linked post was talking about, and not your "Agile==good" metadefinition.
I know - it does come across as the one-true-scotsman argument at times.
Disclaimer: I'm a fan of agile. I even seem to be turning into one of those evil consultant people in my old age (but only just recently - and I still code :-)
I'd urge agile sceptics to put aside some of the crap they see in the real world. Go take a look at the original sources (e.g. both of Beck's books on XP are fun reads - and short :-). Take a look at the Scrum guide (http://www.scrum.org/Scrum-Guides) - it's only 16 pages long. Does that look like a heavy process?
Agile got popular in the early 00's coz it helped many teams get better. It then suffered the curse of getting popular. Everybody and their dog started doing it badly, or relabelling what they were doing already as agile. Pretty much every agile method came from developers. XP in particular was process that came from developers observing what worked well for them. Ditto Cockburn's Crystal methods. Scrum worked so well because it kept management out of the loop during sprint development (and that's also one of it's failings... but that's a different argument :-)
To pick a pure development analogy. Large chunks of the OO code I see isn't really OO code. It's some procedural code and some pure data structures wrapped up into classes and methods. Because of this it doesn't reap the benefits that good OO code provides.
Because I've seen good OO code, and because I can write vaguely decent OO code, I can see that. I can see the difference between the surface artefacts (classes and methods) and the underlying philosophy of an OO breakdown.
It's the same deal with agile a the moment. There are lots of places that are "doing agile" that are only touching upon a couple of the surface artefacts, but not actually making any of the philosophical changes that mean they build better code.
For me this doesn't mean agile sucks, any more than it means object-orientation sucks.
I'm sorry - I could have been clearer. The point I was trying to make was that the process of reading to determine whether it is a heavy weight process is not an onerous one.
You're yelling at the wrong guy. What @debacle said was "You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one." That's decidedly not "cowboy programmer bullshit". If your response was directed at @fingerprinter's statement that "having nothing and good developers you trust is always going to be more productive", then maybe you should have been rude to him instead of @debacle.
I think @debacle nailed it. One of the major problems with all the processes I've ever seen is that people (large corporations, mostly) expect them to solve the problem of having teams made of bad or mediocre programmers. It's quite similar to the idea that you can solve just about any problem with technology.
No it's not. It's pretty well documented in the scientific literature that making people who've mastered something (eg. doctors, airline pilots) work from intuition a lot of the time, so following a set of prescriptive rules inhibits their performance.
If you're still learning how to do things, then how-tos, recipes and best practices like Scrum will help.
"having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.