There was always a great deal of fuzz on development methodologies, especially because of their creative or funny names, that lead people into believe that any one of them would save their project.
Funny though, that all of them have, within limits, the same basic concepts: design, implementation and deployment. All of them say that the interaction with the client is fundamental. Furthermore, that the need of a mediator between developers and the client is fundamental. Project managers, product owners or masters, they always value the customer’s point of view and, one way or another, they help the project to stay close to the original plan.
If you dig the Wikipedia or books about all of them you’ll find that they’re good for a bunch of situations and bad for a whole bunch of others. You’ll also find that some completely different methodologies are good for similar projects with tiny differences and truth is, you never know in which case you fall into before falling into it!
Wizards, Gurus and Masters
Your project is going berserk and you need a saviour, who you’re gonna call? You browse the internet in search of new methodology, you find Agile or Scrum or XP or whatever and post a new job on your company: [methodology-name-here] Master.
He comes, whatever master he is, and start pointing the obvious problems you have and what his new methodology brings to solve it. It really looks like it’s gonna work and it probably will, but the true question is: was it the new methodology that saved it? What if, instead of Scrum you have chosen XP? Or any other buzzword that will come next month?
Learning from the past
If you’re in the development field for a few decades you’ll remember the bright glow that RUP had in the late 80’s. I particularly love the graphic where they show the amount of work of a particular type you have on each phase.
Even if they had measured the men-hours on each phase to the required granularity to produce that graphic with the average of all projects measured, it’d still be absolutely pointless. But they didn’t even have proper tools and the reality they were trying to model wasn’t even capable of being modelled in the first place.
But that was beautiful, people in the 80’s liked graphics and colours very much. You might remember the boom it was if you had a colour computer with a graphical interface at that time (Amiga lovers should smile now).
All in all, RUP became the standard for years and years and still many big companies still use it with a large margin of success on their projects. But for small projects it wasn’t viable (I’ve learnt it the hard way) and people had to come with new ways during the 90’s. Then, nice graphics wasn’t enough, the new fashion was funny names like eXtreme Programming, Agile and so on.
So, back again where the first attempts didn’t worked out as expected (pair programming is a bit pointless anyway), new methodologies came, one after the other, and today we’re still saving projects with methodologies that will need, in the near future, new saviours.
What’s the point of trusting project to a methodology that wasn’t proven to be effective? As a matter of fact, is there a way of proving anything at all about methodologies? Of course not! Each case is a different case, all you need is common sense. (John Lennon would disagree).
The Agile guru will drive your project his own way, to prove his method is effective. The same with Scrum Masters and XP Wizards but following a fixed scheme methodology on random projects within the same company is to ask for the need to restart again next decade.
If your project is small enough, if your company is focused enough or short-sighted enough, you might well stick to one of them you like most and be happy. You’ll probably make a lot of money for a long time, the same way Microsoft and Yahoo! are still doing for the last decades, but the quality of their software (and yours) puts the big ball of mud as a special case.
Worse, those companies are recently jumping from one methodology to another every year. Each new project manager that comes in brings a new salvation, screws up even more and goes away to give place to a new wizard to screw up a bit more, on and on.
If you need to be agile, use common sense. If you need quality, testability, deliverability (that’s a new word, isn’t it?), use common sense. All methodologies bring something good and lots of bad things for your particular case, get those that maximise your investment (but are still compatible with the other you’ve chosen) and you’ll be fine.
Wizards, Gurus and Masters will defend their ideas, not your projects. Ask your developers what they think. Have as many meetings as you need, not the crazy-madness of one a day because we developers know that a half-hour meeting does not take half-hour! We know that the client’s vision is fundamental, we know that software must work all the time, all of what’s delivered, that tests should always work independent of what happened last weekend.
A bit different from the others, Agile is more of a list of recommendations than a formal methodology and that makes a big difference when adopting the central ideas to your project. If you’re a developer, get to know it more. If you’re a manager, ask your developers about it.
The Linux Kernel
Funny though, that Agile and such was made for small and quick projects while RUP is still used by some massive development, apparently with good quality and testability. But the biggest project of all times, with the biggest team of all times and the fastest growing code of all times does not use any of those fancy-named methodologies: The Linux Kernel.
Greg K. Hartman gave a very inspiring talk about the development of the kernel and how there is hardly any project or group of projects in the world that can ever get close to the dynamics intrinsic to the Linux kernel development. (link from Rodrigo, thanks!)
If you’ve read about the kernel people you probably know how common sense is not one of their strongest attributes, but because the project has no owner, no stakeholder, it just works and the sense of the majority is the common sense in the strict sense (sorry for the joke).
Each one has its own ways of doing things, ownership is shared, and sense of responsibility is beyond any level I’ve seen on industry or academia. It just works.
If you want to save your project from doom, do like the kernel guys do: use common sense.