In a recent exchange on InfoQ, regarding the recently released Voke report on Agile, I opined the following:
I just wanted to add and concur that originally these were called “lightweight” methodologies and I think the term is accurate — whether they are for lightweight projects or lightweight developers.
Maybe some fraction of SW development does indeed fall into these categories — or yet another “startup/Minimalism” category.
One of the major points to happen from the “Snowbird” conference was the jettisoning of the term lightweight for “agile”.
It was thought that “lighweight” would indicate non serious or disposable. So — after much discussion “agile” was settled on, as a more marketable glittering generality.
However, if said methodologies, had been indeed marketed, under the more realistic and accurate name of “lightweight” we wouldn’t be seeing the problem we see today.
The fact that there was a deliberate effort to make this a universal solution, driven, possibly, and only possibly, of course, by the notion of a future profit potential, have we seen this phenomenon.
Let’s call a spade for what it is — if this is a lightweight methodology for lightweight programmers or lightweight product owners or lightweight projects in general, fine call it that.
I can certainly see if someone has a $15k budget for a project, and “BUFD” would cost $10k, sure, jettison that, let’s code ‘n’ fix til we TDD towards a solution.
But that is what it is…a solution for some small projects or some serious unknowns…not a universal panacea.
In other words, I agree there is a time and a place for lightweight methodologies, and the clarity to call them what they are.
The fact that “agile” in a rush to stampede the world, has, mistakenly assumed all projects fall under their “lightweight” domain, is the crux of the issue we are facing today.
The Voke report, as well as most real world market information, suggests that agile is far from panacea.
It may indeed be appropriate for lightweight work and let’s celebrate that.
But when heavy lifting is required, perhaps a different approach is called for.
Let’s stop even referring to “agile.” Let’s call it what it is — lightweight.
A spade is a spade, it has it’s purpose, and so do Lightweight methodologies like Scrum and XP and most of Agile.
There is no need to get a bulldozer when all you need is a shovel, shall we call a spade a spade finally?
PostAgilist
Post Agilist 
I’m new to your blog, but fascinated. Not sure if this has been brought up before, but why do so many people frequently want to take ‘a good process idea if used carefully, and as intended’ and turn it into a form of quasi-religious dogma?
Hi Bob
Excellent questions.
I would say, that, historically, people have taken good ideas, and then tried to market/etc them far beyond their means, for several reasons, but one of which is to make money.
Let’s say, there was a good methodology or whatever, X, and it was appropriate in say, 20% of the cases.
That’s still a big piece of the pie, but bear with me.
If you want to sell a customer, then, honestly there is only a 1 in 5 chance that the customer is in need of the product/service at all, let alone that s/he will choose you as the vendor.
However, if one markets something, as 100% the right thing to do, for everyone, then one only has to contend with the well-are-you-the-right vendor question.
So to me, yes, sorry to say, if it looks like a duck, quacks like a duck, and makes money like a duck in vegas, then, well, the money aspect would be a likely contender for the driver here.
I’d like to see a world where vendors can make an honest living without feeling the need to promote panaceas to simplify the sales and marketing efforts.
Thanks for your kind comments,
PostAgilist
Personally I don’t think there is much that is “lightweight” about agile, except that you can theoretically pull the pin earlier because there is a focus on releasable software from the outset. Techniques such as TDD, Continuous Integration, Continuous Delivery, etc, take a lot of effort and discipline, and working iteratively often adds significantly more overheads in extra meetings, extra releases, a focus on getting things working earlier & continually refactoring, etc. In most of my experiences, agile is perhaps _less_ lightweight.
The tradeoff obviously is the time recovered by avoiding a BDUF phase, although in all honesty, most reasonably sized agile projects follow a RUP-like project bootstrapping phase of Concept & Initiate prior to delivery, which is really just a collaborative analysis & design phase (which from a cost point of view, is perhaps even more significant given the investment of so many people’s time).
There is certainly less ceremony in producing non-executable artefacts prior to the delivery phase, with less of a focus on filling out unnecessary sections of a template and more about providing the right information, preferably in person, but as you’ve pointed out before, most delivery organisations have already found a pragmatic balance to achieve a sensible rhythm in this phase anyway.
Well, I think the point your trying to make at least in the first paragraph, is that, just because something is lightweight for lightweight jobs (like a shovel) doesn’t mean that it is still “lightweight” for bigger jobs (like a shovel).
Eg, if you want to level out a soccer field, you’ll waste far more time with a shovel than with a different tool.
I would agree with that 🙂
PostAgilist