Tutorial :How to stop Lean programming becoming Cowboy Coding? [closed]


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'?


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.


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?


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?


I suppose if you keep some kind of code review, it can't go too wrong on this side. If no one know what the other programmers are doing and how they're doing it, then you might have crossed this line.


There's probably no definitive list of warning signs which if you see tell you you're in cowboy territory. Personally, if people are releasing untested code, developing features which aren't definitely understood, or in anyway rushing work or ignoring warning signs I get worried.

Better to use your own judgement. Hopefully, since you're asking the question you're the right person to be sheriff.


Cowboy coding is rogue coding. The only thing that allows rogue behavior is an absence of oversight by an authority.

Agile's "Self-Organization" is often abused to the point of rendering the term mostly meaningless as development teams opportunistically re-interpret it to mean "Self-Determination".

A Lean organizational approach to management can be a marked difference from what we're used to - even from Agile teams. And it's this issue of organization and direction and its organizational mechanics that makes all the difference.

The adoption of Lean Product Development in software is still quite young, and unfortunately suffers quite a bit from distraction-by-Kanban. But this is to be expected - the most externalizable aspects of a method are usually the first to be recognized and adopted, and these are usually the most mechanical aspects. Kanban is a flagrantly mechanical part of Lean. But it's only one part.

Lean is an organizational change much more than Agile was. If you don't change the role of directors in the organization, then you'll likely just end up accessing only the most material and mechanical aspects of Lean, and likely in the most naive ways.

To keep anyone in any organization from going rogue, they need to be directed to fulfill expectations. The role of the director in a Lean organization isn't just a bully, though. A director in a Lean organization (development team, etc) is also a skilled worker and is capable of teaching others the skills necessary to become ever-more proficient at fulfilling the expectations that they have accepted responsibility for.

Whatever specific processes you put in place (code reviews, pairing, incentives, etc) depend on far too many factors that are particular to your organization at the particular moment that you happen to be considering them. The effort's director should understand how to enlist the collective brain power of the whole team to find good solutions or avenues of exploration, experimentation, and learning, and to make a decision for the best - even if it occasionally means contradicting the collective (especially if the collective is young in Lean ways).

Unless your organization gets utterly distracted from weak directorship problems by Lean intellectual materialism, like Kanban, for example. If you've got people going rogue, you don't have a methodology problem, you've got an organizational problem. And if you've got an organizational problem, you've inevitably got a directorship problem, and a problem of unproductive uses of authority.


  1. Never forget your automated unit tests.
  2. Never forget your functional tests.
  3. Never forget your tests.

(I've been guilty)


there is less and less formal process. At some point we will be back to Cowboy Coding...

The irony of Agile/Lean/Scrum "process" is that less formal process will NOT lead to cowboy programming.

While these methodologies prefer "people over process", process is not completely abandoned; management is still required. An at the end of the day you still have a commitment to your customers and deadlines. These commitments should rein in the cows.


"what processes cannot be safely eliminated in Lean's drive to eliminate waste"?

That's a very general question which is hard to answer precisely.

While you are throwing out management processes that produce no value, you need to include more technical practices such as those found in eXtreme Programming. Most agile coaches I have talked to consider Test Driven Development, Pair Programming and Continuous Integration to be a given when they are working with agile adoption. It is very tough to get away with "cowboy programming" with these techniques in place. If I were worried about the code getting out of hand, I'd throw in some code reviews as well.


Hire (or deputize) a sheriff, and corral the code so that it doesn't just get committed but rather gets looked at by the whole posse.


Here's where the value of a ScrumMaster/Lean/Agile coach comes in. Whoever fills that role on your team should be able to detect when the team's self discipline is slipping and remind the team of the commitment they've made to each other about the quality of their code.

The other thing you can do is adjust the containers. Add code reviews to your Kanban board and then put a limit on it to ensure it gets done. Better yet, require all code to be written in pairs for a few weeks so that good habits get reenforced and no one can claim ownership on sections of the code.

Finally, consider that perhaps your move away from the formal process of Scrum was a bit premature. The rules of Scrum are there to teach you a completely different way of thinking and working. If the values of Lean and Agile haven't been ingrained in your team yet, it's very easy to slip back into old habits. This is where the strict enforcement of the rules of Scrum can help you until your team is ready.

Remember, Kanban is a tool. If you are not consistently applying Lean and Agile principles to its usage, you won't get the full benefit.


Both Lean and Agile involve minimising waste in a very specific context: delivering value.

If you stop using processes that help you efficiently produce value, then you will either produce less value or produce value less quickly.

Since both Lean and Agile techniques involve measuring how you are progressing in the production of value, you should be able to tell when you cross the line and eliminate a useful practice.

If you're not using velocity or cycle time to measure your delivery of value, then you have already crossed the line!


What's wrong with Cowboy coding? If you start to see poor quality, code delivery taking longer and longer, not meeting end user expectations (or whoever is paying), then its time (and I'm a PM saying this). When you have a good/solid programming team, the need for formal process isn't needed - its usually internalized - good programmers follow good form/process naturally - I think that a lot of process is put in place for the weaker performers which in many cases negatively impacts the good/great performers. A good project manager needs to balance process to the specific situation...lead/follow/get-out-of-the-way type of approach


Engage the customer perhaps, so you dont write a theoretical system under a BAU budget that the business dont actually want? Talk to your manager(s) more.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »