Taming the Wild West: the Differences between Agile and Cowboy Coding

One of the strongest arguments for Agile is that it’s not Waterfall. However, not everything that isn't Waterfall is Agile, a fact that’s not always understood. This misunderstanding hurts the Agile brand when people familiar with only Waterfall begin associating all other methodologies, including a lack thereof, as Agile. I want to be very clear about this: Agile is not Cowboy Coding, and Cowboy Coding is not unique to Agile teams. It is important both to understand how Agile and Cowboy Coding are different and what Cowboy Coding looks like so that you can identify it on your teams (yes, even Waterfall teams).

The Loner

One of the easiest signs of a Cowboy Coder is that he’s a loner. He may be working under the name of Agile, but there are no Agile methodologies or frameworks I’m aware of that support such behavior. In fact, the backing principles of the Agile Manifesto state, “Business people and developers must work together daily throughout the project”; “Build projects around motivated individuals”; “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”; “The best architectures, requirements, and designs emerge from self-organizing teams”; and “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The manifesto, its principles, and all Agile methodologies and frameworks I know of are very human-centered with an emphasis on collaboration.

If you have a loner on your team that insists on working in a silo, there’s a possibility that you have a cowboy in your midst. Try to rein them in using mandatory meeting/ceremonies that promote meaningful conversations and practices like Pair Programming. If they absolutely refuse then you will likely end up spending considerable time managing the work around them – holding ad hoc conversations, formal code reviews, knowledge transfer workshops, etc. – with diminishing returns.

Straight to Production

Working directly with Production code or with a source code repository that isn't versioned is a bad idea. Don’t get me wrong, I love Continuous Delivery and working off the trunk, but a software development team must be very mature and disciplined to make this work. They use feature toggles and branching by abstraction to protect code that isn’t ready for Production. They build test suites around the code so that each commit is verified against regression. They do their due diligence to make sure that a change isn't going to blow up if it’s pushed to Production. Cowboys, simply put, don’t.

If you find yourself consistently in a situation where the same person or people are making changes directly to Production without due diligence then you might just be working with Cowboys. Have them read up on DevOps and Continuous Delivery so they can learn the right way to get changes to Production quickly. Emergency situations that require quick, non-vetted changes to Production should be avoided at all costs.

Wastes of Time

The Cowboy will often refer to Testing and Documentation as a waste of time. They may even commit the cardinal sin of Agile, reciting the Manifesto blasphemously: “‘Working software is the primary measure of progress’; anything else is just a waste of time!” To those people, I would ask them to define “working”. Does it pass the Acceptance Criteria associated to the work (or did you even bother to ensure you had Acceptance Criteria)? Can anybody actually use it, or is it too buggy or complex? Is anyone other than yourself aware of the assumptions made around input, output, workflow, etc.?

Without proper testing and documentation, you can’t prove your software works nor can anybody understand how it works. With that being said, if your tests and documentation don’t contribute to the value and usability of the software then they are, in fact, a waste of time. Focus your testing efforts on tests that actually stand a chance of failing and finding vulnerabilities. Don’t spin your wheels creating “write-only” documentation. This is the approach that Agile espouses; anyone who says tests and documentation are altogether useless is operating with a Cowboy mindset, not an Agile one.

“Emergent Architecture”

One of the backing principles to the Agile Manifesto states “The best architectures, requirements, and designs emerge from self-organizing teams”. There are those who believe this means “just make it up as you go.” That’s not entirely accurate. There still needs to be intelligent design, and that design needs to make the software as easy to comprehend and maintain as possible. As another principle clarifies, “Continuous attention to technical excellence and good design enhances agility.” This means having a thorough understanding of the latest design patterns and practices. It means taking the time to refactor working code into something better. It means taking a little bit of time up-front to design what you think will work and adjusting as you go.

Agile developers do not shoot from the hip. They take pride in their applications; they have a sense of ownership. They will throw research spikes, read books, build proofs-of-concept, attend conferences – do what it takes to build the right thing in the right way. You’ll spot a Cowboy by their purposeful lack of direction, sticking code wherever they please with the sole purpose of “getting something to work” so they can move on to the next thing. If they do it in the name of “emergent architecture” then call shenanigans. That’s not architecture, it’s just reckless.

Somewhere to Hang their Hat

The good news is that cowboys can be tamed if they can come to appreciate the practices, tools, and frameworks that Agile provides. Cowboys won’t jump on the bandwagon just for the heck of it. There will always be some that refuse to be tamed, but many will see the benefits and forsake their wandering ways once you give them a safe place to hang their hat.

One of the great things about reformed Cowboys is they are used to developing quickly and cross-functionally. If you arm them with XP practices, Agile tools, a Kaizen mindset, and continued training and development, they can become model developers that contribute quality software time after time.

Just don’t make the mistake of trying to get them to do something for which there is no tangible benefit. They don’t take too kindly to that.

Bottlenecks: the Enemy of Agility

I am the Release Train Engineer for one of my company’s first Release Trains. One of my early struggles when we first adopted the Scaled Agile Framework was understanding what the responsibility of the System Team was and how to concisely articulate it to others. That understanding finally came during the Quick Start event where I heard Alex Yakyma say the System Team identifies, manages, and eliminates bottlenecks. What a powerfully simple mission! I’ve since dedicated time to understanding and helping the team understand what that means, and this is what I’ve come up with so far.

First, how do you identify a bottleneck and what does it mean to be a bottleneck? Sometimes this can be rather obvious, but often it is difficult to separate the symptoms from the root cause. This can be a process, practice, culture, etc. I have come up with a process to help myself and my System Team identify bottlenecks.

First, envision what it would be like if we could deploy to Production a dozen or more times per day. Not that we would, necessarily, but what would it take to be able to roll new functionality to Production the same day we get the request? Second, document our current process and lead time from conception to Production. Third, identify the gaps between our current process and the ideal of Continuous Delivery.

If you find yourself defining symptoms and not the root cause, start using a Lean perspective and start asking “Why?” For example:

“It takes too long to get a package to Production once it’s been approved.”
“Why?” “Because we have to find someone who has the bandwidth to get it deployed.”
“Why?” “Because we do not have an automated deploy process in place.”
“Why?” “Because our application runs on WebSphere in a Mainframe environment, and we can’t set up auto-deploy until it’s migrated to a Linux environment.”

Here we have identified the primary bottleneck – the environment on which our application lives in Production – by asking 3 “Why”s. Expect to ask as many as 5 “Why”s before getting to root cause.

Next, we need to time box the bottleneck. This basically means you’re going to work with what you have for the time being and basically “deal with it”. This is a temporary phase until you are able to eliminate the bottleneck. You should have a timeframe for how long it is acceptable to manage a given bottleneck and hold yourself to that timeframe. You may not always meet your goal, but time boxing is the first step in giving the bottleneck some form of finality.

Last, we need to eliminate the bottleneck. The easiest solution is to just do away with it – stop doing it outright. This is also usually the least feasible. The best solution is usually automation, simplification, or combination. If you can automate it, automate it! This way you’re not diminishing the task, you’re making it take less time. If you can’t automate it, see if you can apply Lean thinking and simplify it somehow. Can you get what you really need with less? Agile encourages just-in-time and just-enough to limit the amount of waste we allow in the software development process. One of the backing principles to the manifesto states “Simplicity – the art of maximizing the amount of work not done – is essential”. Finally, if you can’t automate or simplify the task, see if you can combine it with another task to “kill two birds with one stone”. Pair Programming, an XP practice, is a great example of this – you’re essentially rolling your development, code review, and knowledge sharing all into one activity that typically doesn’t take any longer than development normally would.

Once you’ve eliminated one bottleneck, repeat the process indefinitely. Kaizen mindset tells us there’s always room for improvement and it’s always urgent that we improve. By all means, take the time to acknowledge and celebrate your improvement, but don’t get complacent.