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]