The Lightweight Tweetstream

Once we had "lightweight methods" as a frequent topic of discussion. It's still the movement I pursue.

Some innovators came through and invented radically different ways of working, usually through collaboration and teamwork.
The idea of simplifying the workflow was met with much enthusiasm in some quarters and surprisingly hot disdain and outraged anger in others. Still, those practicing lightweight methods produced software quite well, so lightweight methods persevered. 

Lightweight methods took the name "agile", which is a perfectly good name.  Even so, I'll not use it much here. 

Lightweight methods pursue "the least process you can afford" at all times. 

• If you can afford less documentation, then cut some of the documentation out.
• If you can afford fewer queues and piles, then streamline your process. 
• If you can afford a cheaper alternative to approval cycles or big plans up front, by all means, use the faster cheaper alternatives.
• Can you replace an expensive, accurate method with one that is cheaper and less accurate, but the result is "close enough"? Then replace the expensive method.
• Are there ceremonies and meetings you can cut out? Then why keep having them?
• If your process quits working, then you may have less than you can afford, so you need to raise it up a notch or try simplifying a different part of the process.

Cool analyst techniques emerged. Techniques like story mapping and example mapping make it possible to release a feature in end-to-end "slices" so that the system always works, always provides value to some users (even if the whole feature-as-specified isn't fully written yet).
Lightweight methods sometimes find expression in safer practices, so fewer preventative governing processes are needed. 

• If you integrate code all the time, then you don't have big ugly merges. 
• If you work in groups, you don't need as many code/test reviews.
• If your business/customer person is available, they can simply answer questions instead of writing explanatory documents. 
• If you micro-test continuously, you can avoid a lot of bug fixing later.
• If you automate boring, repetitive tests, then you can test more often and faster.
• If all the dull testing is automated, then humans can concentrate on the interesting testing tasks.
• If you keep code clean, you can make changes quickly without relying on the original author to explain and edit it for you.
• If you have smaller batches, you can release more often.
• If you test and release more often, releasing becomes a non-issue.
• If you build through iterative enhancement, then you can choose to stop elaborating a feature once the remaining bits aren't very important.
• If you collaborate all the time, you will need few meetings and documents (cf Mob Programming).

And of course, the biggest thing that all the lightweight methods seemed to do was (as Chet Hendrickson said) to "get the software working very early in the project and keep it running throughout."

Continuous Delivery and Continuous Deployment came along, enabled by new technologies. These help to further drive software development methods to become even more lightweight.

Sadly agile methods, in an attempt to scale up to very large organizations and automated management tools, quickly became heavyweight. Or, rather, a lot of heavyweight implementations and processes starting calling themselves "agile."  Some of the diagrams and methods require complicated diagrams and many roles and rules to operate, and are easily on par with the heavyweight methods that Agile attempted to replace.  

A series of "Nos" emerged.  NoEstimates,  NoProjects. No silos.

Likewise, limits arise. WIP = 1, Limited Red Society.

This is a familiar cycle. There is bloat, then reform, then bloat, then reform.
Rules tend to accrete. Someone has a misalignment - we make rules to prevent or recognize misalignments. People make mistakes, and we make rules to rule out the mistakes. People miscommunicate, so we build rules and documentation to correct their communication. People fail, and we add process and rules to force them to succeed when we want them to.

Over time, the basic rules of large organizations make rules and standardization and conformance look appealing, and we need sheriffs to make sure the rules are followed and auditors to check that the sheriffs are doing their jobs, and people-watchers to watch the people-watchers who watch the people who ensure that the rules are followed.

Me, I back the plucky group of rebels who try to downsize the process. I especially back the ones who replace rules and processes with human dynamics, human alignment, curiosity, concern for others, and healthy doses of modern automation to drive the dullness out of their daily work.

 I particularly like replacing recipes with values, curiosity, trust, alignment, understanding.

Heavyweight processes run on permission, rules, restraints, limits, conformance measures, numerical goals.

Lightweight methods run on agreements and experiments, enabled through trust and alignment.  This will always be the movement I pursue.