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.
No comments:
Post a Comment