Lightweight Methodologies

Coined by AlistairCockburn, as far as I know.

[Software development] methodologies that focus on the use of as little process as possible to obtain good results. Often proportioned to the size or risk of the project.

ExtremeProgramming strives to be the lightest methodology worthy of the name, although the Chaos methodology seems to have less in it than XP ...

Instances:

Not sure if EvoFusion belongs on this list?

See also LowCeremonyMethods

Low ceremony says to me that things are informal. Lightweight says to me that there is not as much documentation... but I can see that some people might also associate "lightweight" with weakness. Ah well, some people don't like the name ExtremeProgramming either... --JasonYip

the use of as little process as possible...

We need a better definition than this. How do you measure how much process there is? Even if one does nothing but write code, there is still as much process present as one cares to observe. Is this about creating a separation between coding activities and non-coding activities? If so, let's be clear on that. --WaldenMathews

I usually think of a LightweightMethodology as one that is not document-based and has few but powerful formalisms that are loosely coupled with each other. Hmmm... should this say practices rather than formalisms? Either way, I think loose coupling is a key for LightweightMethodologies. One should be able to use a practice or formalism without having to pull-in a bunch of related practices that in turn pull-in others. I think it is also a given that the methodology must be rapid. -- RobertDiFalco

That doesn't necessarily fit with XP. RefactorMercilessly is not a practice you want to pull in alone.

Maybe not. I wasn't thinking of XP so much but just how I define the term Lightweight Methodology. -- RobertDiFalco

Okay, and how about lightweight motherhood? -Walden

Har, Har. Honestly, this is just what I think of for a LightweightMethodology. I have no idea whether it is an appropriate or correct definition. --rad

Is the military concept of "minimum force" helpful here? In CRED we'd define lightweight mainly by DocumentToDeliver. Building such closeness to the customer that goals for the next delivery can be ScribbledOnOnePage and verified by deployment. -- RichardDrake

Key aspects of LightweightMethodologies as identified in MartinFowler's TheNewMethodology:

Light methods are adaptive rather than predictive
Light methods are people-oriented

--- I like this. I think "adaptive" is very closely related to my assertion about "loosely coupled practices". --RobertDiFalco

I also like MartinFowler's characterization. In MethodologySpace, I introduced the notion that the weight of a methodology (conceptually) is its size times its density, where "size" is the "number of elements" it contains, and "density" is the "rigor or exactitude" that an element calls for.

I like this too...

I haven't ever tried counting and multiplying, but you can spot if one is larger and denser and heavier than another. CrystalClearMethodology calls for a total of 22 work products and a small handful of practices and reviews. XP calls for perhaps 8 work products, and has another similar number of standards to follow and a similar number of practices. XP calls for those to be done with greater rigor than CrystalClearMethodology does. XP is definitely "smaller", but is also "denser". When you multiply them out, I would guess that XP is "lighter", but perhaps not by much. In contrast, PSP/TSP and CleanRoom and most ISO9000 processes have several factors more work products AND call for more rigor in using them, so they are both larger and denser, ergo heavier.

Adaptive as it was used in Martin's paper refers to the method's strategy.... A light method tends to adapt to changes as they occur while a heavy method would tend to try to predict changes up front. As much as I can see, adaptability of the process would seem to increase the range of applicability and acceptibility. I'm not sure if that's all there is to AdaptableMethodologies though... --JasonYip

Both Adaptive in Jason's sense and people-oriented I think may be necessary factors. The idea in lightweight methodologies is that person-to-person interaction replaces writing. Ergo, replace written work products with people actions. Ditto with delivered code replacing "promisory notes".

There does indeed seem to be a trend toward people-oriented and adaptive methodologies these days (2000). --AlistairCockburn

I'd like to applaud the movement in the direction of LightweightMethodologies. XP is only one example. Coming as I do from the pre-deluvian days before there were any software methodologies, I've watched the tower of Babel of one size fits all methodology bloat that has led us to UML which is a potpourri of modeling methods cobbled up by combining earlier and better versions of the one size fits all type.

Somehow all this bloat misses the point. A methodology is like a notation. A notation that is complex is of little help because it doesn't shrink the problem in any dimension. I would compare a lightweight methodology to a heavyweight methodology using the analogy of a geodesic dome. The effectiveness of the methodology is the volume of coverage it provides, the weight is the tonnage (the human effort) it consumes. Methodology is something that is adopted to accomplish something, but which seems often to become an end in itself. The XP practice of Doing the Simplest Thing that will work -- is an example of something that is motived by the right spirit.

I teach PSP, not because I think the PSP process embedded in the class is the right one -- but because the adaptivity that is taught and the consciousness of the problems that are addressed is fundamental.

We need methodologies that 1) work, 2) shrink the dimensions of the problem space, 3) are easily used and communicated, 4) are stable in time and space (any methodology that works right now is better than one that will do everything if you just take yet another course from yet another guru). As a Engineering Director whose native language was FORTRAN but who has dabbled in just about everything -- the illusion that change is progress is something that has dominated the world of software since my youth and does not seem to be changing a whole lot. --RaySchneider

To me, the "lightweight" in LightweightMethodologies is a measure of how much activity is required simply for the sake of formally complying with the methodology. The methodology is an artificial scaffolding set up to support the gloopy, soupy, organic mass of programming activity. The ratio of scaffolding to supported mass is a measure of how efficient the methodology is designed.

Or, to put it another way: you want more engineers to work on the rocket than the launch arm that supports it on the pad. -- BillBarnett

I was looking for a way of convincing management at one of my clients that lightweight methodologies would help them get out of their tar pit. Eventually, I managed to come up with the distinction that "lightweight methodologies deemphaize production and emphasize productivity". Production here is defined simply as "producing things", whereas productivity is defined here as "the rate at which requirements are being satisifed". Any production that is not productively contributing to requirements satisfaction is bureaucracy. That seemed to sell it to "the big wigs", and "authorized" toupees (little wigs) like me and the client's developers to then shun bureaucratic work that had previously kept projects dragging on forever. -- AnthonyLauder