Dealing With Cowboys

"The coolest thing with Scrum," he said, "is that you can get rid of your long requirement phase and start deliver at once. You can also throw away your copy of MS Project. You don't have to create any big design documents or spend time in test phases any more. Release monthly and get paid earlier!"

Confused stares.

"Doesn't that sound great?" he continued excitedly.

More confused stares. Awkward moment.

"What's going on here?" he thought.

Muffled laughter.

"But we aren't doing any of that," the manager responded. "It sounds expensive and wasteful. Besides, we already release several times a week. This Scrum thing seems pretty pointless to me."

Long pause.

"I trust my tech lead and it looks like he was right again: We are already doing it the best way possible. We won't be needing your services. Thank you for your visit."

What's going on here? Is Scrum guy wrong? Who laughed? Why?

To begin answering this, remember that agile was conceived partly as a response to cumbersome, rigid development methods all the rage at that time. Check the agile values and see for yourself. The message is "less cumbersome". Agile is "less cumbersome". So it's quite natural that selling points for agile focuses a lot on promises of more flexibility and less ceremony, i.e. things that large organizations struggle with.

On the other hand, there are approximately one thousand billion small companies out there and I bet few of them are using cumbersome today. It's simply not doable when you're fighting for monetary survival every month and competition is fierce. You must deliver today to keep your nose above the water. So it's easy to to fall back to cowboy programming.

Cowboy programming is what you are doing when have no method to follow, a non-process process. Anything goes and prioritization is based purely on gut feeling and the programmers do whatever they feel is right. The cowboys are left to themselves while management are waiting for results. Every day brings a new approach. Planning, if any, is ad-hoc and everything is event driven.

It takes a lot of self confidence and ego be able to "lead" a cowboy process, but the individual rewards are plenty. Cowboys are heroes who works to save the day, their egos addicted to the admiration from those they save. It's their duty to fix everything. They celebrate overtime and work all night to create bugs, which they fix and then reap the rewards. Clapping of hands! It's weird to see it action, amusing almost.

[Please note that I'm using the term to describe the entire process and not just the coding part. Programming is creative work which requires inspiration and freedom, so in that sense a certain amount of cowboy coding can work wonders for a team. Oh, and not all small companies are cowboy shops, far from it.]

So what happened to our Scrum guy? He got invited to a small cowboy shop and wasn't prepared for it. Ignorant of development practices and supported by his lead cowboy, the manager cannot understand what Scrum guy is talking about. The problem is that Scrum guy is trying to sell agile with talks about "less process" when, in reality, they don't have any. He knows the correct words to use when dealing with large businesses (users of cumbersome), but is completely lost here.

In a cowboy coding shop, programmers have seized control over the product development process and is dragging the business along with them. The process is completely opaque so stakeholders are left in the dark wondering what's going on. The only thing they can do is to nag the cowboys with progress reports and status updates. Or, as in this case, management are lulled into believing this is how development should work and there is nothing they can do about it.

Either way it's a waste of everyones time and we owe it to our stakeholders/clients to let them handle the business, not the developers. I think that should be the focus when dealing with cowboys: wresting control back to the customer and help them slow down their frantic code herding. Pull in the reins if you will.


Read the exciting conclusion in Part II!