Part One – A Response to “Traps & Pitfalls of Agile Development – A Non-Contrarian View”

It is with great interest that I read articles and books that deal
with the “ugly” side of Agile development, especially because my
current team is in the process of beginning to implement some Agile
processes in our environment.  The last thing we want is to see our
adoption of Agile practices fail.  So, we are looking to take “what
works” and implement those things gradually into a system that is
ad-hoc right now. 

I appreciate this blog entry
by Sean Landis and write the following in response to and as a
continuation of the discussion he started.

For this entry, I will focus on Sean’s first two pitfalls:

Pitfall 1:  Agile teams may be prone to rapid accumulation of technical debt.

My opinion:
true.  However, that is not the failure of Agile, per se, but rather a
failure of the Agile community to sufficiently address this reality. 
Agile coaches need to be cognizant of this fact (mine was, actually)
and stress the importance of putting refactoring work into each
iteration or sprint. 

This will diverge from “pure” Agile in
the sense that a refactoring story does not provide a business
deliverable.  But, just as in traditional (or dare I say, “legacy”)
methodologies, the business customer needs to understand the importance
of addressing technical work that must be done in support of the final
product. 

Maybe I have misunderstood, but isn’t one fundamental philosophy of Agile the idea
that we adjust our activities to fit changing needs?  Heck, Agile
itself might need to be Agile here: adjust itself to deal with the
reality of technical debt.  Hint: take a look at Scrum.

With that being said, here comes The Big But: part of what Agile is about is craftsmanship.  In fact I’d have to say that craftsmanship is a driving aspect of Agile and underpins some of its core practices, leading us to fantasize about the elimination of technical debt.  Principles like S.O.L.I.D., Clean Code, etc., though their constituent parts have been around in some form long before Agile, are key components of at least my understanding of Agile.  For me, it is those principles within the context of Agile that are so compelling. And these principles, practiced in concert with techniques such as Test-Driven Development and Continuous Integration, push us closer to the ideal of eliminating technical debt.  Until we reach that perfect state of being, however, we do need to address the reality of technical debt in such a way as to repeatedly and continually produce working software.

Pitfall 2: Successful Agile development presupposes team members will all act like adults.

My opinion:
true.  However, I really think this is a selling point of Agile, not a
pitfall (of course, it depends on your audience).  Shouldn’t we all act
like adults whether we’re developing software, drilling for oil or
serving hamburgers? 

Some of the things I think acting like an adult means:

  • Letting go of arrogance, impatience and condescension. 
  • Doing what you’ll say you’ll do
  • Taking responsibility to be the best you can be
  • Making a commitment to lifelong learning and personal growth
  • Doing your best today, realizing that tomorrow you’ll be better
  • Helping others who aren’t as good, smart, talented or knowledgeable as you, without being arrogant or cocky. 
  • Taking pride in your work and assuming others are doing the same, until proven otherwise.
  • Taking pride in accomplishments to date, but being open to learning from someone who has accomplished more
  • Knowing your limitations, working to stretch beyond them but being willing to ask for help when necessary

Agile
“suffers” from this pitfall because the world suffers from this
malady.  The controls that other methodologies have to deal with this
very fact of human existence are not any more effective than the
emphasis on personal responsibility Agile embraces. 

On a good
team, Agile is self-correcting: the transparency required, the pairing,
etc., all tend to place social pressure on those individuals that are
not “cutting the mustard.”  They either get better or end up leaving
the team because they can’t stand the scrutiny. 

Maybe Agile is actually quite effective at making sure we all behave like adults.  Is that really a bad thing?

Conclusion

I’m
really just pitching my two-cents out there for consideration.  Next I
will throw my feeble mind at Pitfalls three, four and five.  If anything
sparks ideas, views, opinions, contrary or not, please feel free to
respond.

 

[Original version of this was posted 1/7/2009 at http://agilecruz.blogspot.com]

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

This entry was posted in Agile Development, Community, Extreme Programming, I.T. Management. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Comments are closed.