How to stop Lean programming becoming Cowboy Coding?

Question

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

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

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.

Answer 5

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

(I've been guilty)

Answer 6

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.

Answer 7

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?

Answer 8

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.

Answer 9

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

Answer 10

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.

Answer 11

"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.

Answer 12

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.