Me : Sure. This was a first draft of how to use multiple methods when building HS2 (high speed rail) in a virtual world. It's from 2012 roughly, you'd have to talk to @GoAgileGov for more details and how it helped.
Me : Yes. I've got earlier examples.
X : How early?
Me : Oldest ones, mostly photos of whiteboards date back to around 2005 - 06. Why?
X : My boss says the company has to go all agile.
Me : Is the firm bigger than 20 engineers?
X : Way bigger!
Me : Your boss is wrong.
Me : So am I, especially very lightweight XP (eXtreme Programming). Though I suspect you mean more Lean development by enhancing techniques like SCRUM with other artefacts designed for product building and learning?
X : That's not agile?
Me : Oh god yes. There's the "we haven't got a clue but we're just hacking this together" phase ... the genesis of something, the early custom built. This is where agile shines. But then most people don't mean agile when they say it, they mean Lean.
Me : Same thing that happens if you use six sigma everywhere.
X : What's that?
Me : Projects fail a lot and managers start blaming the people not the process, especially if they picked the process. Then eventually you yo-yo.
Me : Yes, if you're a six sigma shop and you've got failing projects then someone will use agile (or lean) somewhere for a more "innovative" project, it'll work (often with luck) and some manager will go "we're going to use agile everywhere". The cycle then repeats.
Me : Well, it does require people to understand what is being built, the landscape of the components etc. Picking one is just easier and saying you need to use appropriate methods exposes more risk to management.
Me : You have to make a choice for the component and then build the team skilled in the right approach, the right attitude. It's far easier to pick one method and then just blame people for not doing it right whilst claiming your chosen method works everywhere.