Q:

How to stop Lean programming becoming Cowboy Coding? 

My team has been progressively adopting more and more lightweight methodologies, moving from Scrum to Lean/Kanban where there is less and less formal process.  At some point we will be back to Cowboy Coding; indeed I fear we may already be on the border line. 
Where can the line be drawn between a very lightweight Lean and Agile process and anarchy?  How will we know when we have crossed the line?  And how can we prevent ourselves from crossing the line? 
The question might also be phrased as, 'what processes cannot be safely eliminated in Lean's drive to eliminate waste'? 

A:

When something about the code is known or manageable by only one person in your group, you are under a big nice red-glowing "Saloon" sign, and you are basically pushing the doors. 

A:

Presumably you're worried about the effects of cowboy coding:

No requirements
No design
No testing
No feedback from users
No schedule
Unmaintainable
Bus factor
...

So long as you have a plan/mechanism/process to avoid these ill-effects, then you're Ok; right? 

A:

The question of when is a task/story/unit of work done comes to mind as part of that line.   If you require tests and that a pair of eyes have looked something over that may help prevent the situation of the rogue developer that wants to be a Cowboy.   Similarly, how does code get into production?   If anyone on the team can push code on a whim, that would be a warning sign to my mind. 
A couple of other warning signs that I'd note are:

Does the team have a coding standard and a commitment to maintain that standard? 
Are there a bunch of code changes from one individual doing "refactoring" that no one else thinks is worthwhile?