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

In the previous two installments (Part One and Part Two), I wrote about Pitfalls 1 through 5 of Sean Landis’ this blog entry.  I continue with Pitfall 6 here.

Pitfall 6: Agile teams have a tendency to focus on tactical accomplishments at the expense of strategic goals.

My opinion: true, kind of.  This is true on all types of teams I’ve been on, Agile or not.  The place I believe this statement might be relevant to Agile is in the word “tendency”.

My
first response is to play somewhat of a Devil’s advocate and ask, “So
what?”  As long as the software does what it’s supposed to do, is
maintainable and makes the business happy, why not leave the strategic
thinking up to the business experts?

However, what if a lack of
understanding of strategic goals on the part of the developers and
architects affects design, which in turn does affect extensibility and
maintainability?  Now, we have an issue, and an issue to which I
believe Agile could be prone because of many proponents’ emphasis on
the principle affectionately termed “YAGNI” (You Ain’t Gonna Need It).

A
lot has been written about YAGNI and I don’t claim to have read it all
nor want to rehash it all here.  Let me just offer two cents and how I
believe it relates to this pitfall.

If we are not careful, we
can end up practicing YAGNI as a knee-jerk reaction to
“design-up-front”.  We must take care it does not infect our planning
and design of software.  Very often our understanding of the overall
strategic goals, especially from a business-value perspective, helps
inform architecture and design. We must be careful not to overlook this
fact. 

At my previous company, we supported and extended a
system used to help originate mortgage loans.  From the get-go, the
system was built around the concept of a Loan Application.  Once
committed to a design that was Loan-Application-centric (by I don’t
know how many millions of lines of code), it became evident to the
developers that the Loan Application really had a parent concept of a
Loan Package.  The Loan Package could contain one or more Loan
Applications. 

I cannot describe to you the incredible
gymnastics we had to perform to retrofit the system to deal with Loan
Packages.  Refactoring was a monumental effort that we were not given
time to address.  To me, this was a clear example of the truth of this
pitfall, and a clear example of how YAGNI could get you in trouble. 

Had
the developers known the business concept of associating multiple loans
with a single property early on in the process (which might have
surfaced had they know the strategic direction of the business), we may have avoided this problem.

However,
I don’t think Agile is responsible for this; I have seen the exact same
problem many times over many years in a number of different types of
shops.  This is an age-old problem, one of which Agile is actually
trying to address.

On the other hand, I do think a YAGNI
mindset is very helpful, especially when practicing TDD/BDD.  If you
work even half-way through Kent Beck’s Extreme Programming Explained,
for example, you will see how YAGNI, when practiced with TDD, helps
evolve a design in a simple, yet elegant way.  In that context, YAGNI
makes sense. 

However, I have seen proponents of YAGNI go so
far with the concept that they kept themselves blinded to important
issues that were just over the horizon that, when discovered, cost a
lot in terms of refactoring, redesign, etc.  It is my humble opinion
that too much YAGNI can be almost as bad as too much upfront design.
YAGNI is good, but must be balanced. Achieving that balance is hard and
very often comes only through experience, trial and error.  Part of
learning that balance is to realize the contexts in which YAGNI makes
sense.

Agile or not, management has a responsibility to provide
leadership on maintaining the proper balance here and provide for a
process by which every relevant practitioner has an appropriate
understanding of the strategic goals the project is designed to support.

Last
point: the intimate relationship Agile practitioners develop with the
product ownership team can provide quite a bit of opportunity to
understand the strategic placement of the project simply because of the
continual dialogue that occurs.  Inevitably, in my experience, business
context is very often communicated as a natural part of these
interactions.  Not always, but often.

Conclusion:

Short and sweet: be careful with YAGNI and understand the business your software is being built to support.

I
remain a firm proponent of Agile methodologies because, in my
experience, they work and work well – better than other methodologies
I’ve participated in.  To me, Agile is NOT the issue.  Managing
ourselves and the software-unfriendly human tendencies that we struggle
with in our profession, no matter the process or methodology, is the
issue.

[Original version of this was posted 1/12/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.

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

  1. Louis Salin says:

    Great post!
    I think the YAGNI pitfall can be mitigated by using some form of DDD. If you have a proper domain model, then it could be easier to detect if you are going to need this or that.

  2. Chris Taylor says:

    Thank you, Louis!

    And yours is a very good point. I have seen DDD help with exactly this pitfall.

    Sometimes, though, there are bound to be issues that fall through the cracks despite our best efforts. I rely heavily on TDD and Continuous Integration to assist with refactoring exercises that occur when our understanding of business concepts undergo refinement.

    All in my humble opinion…

    Thanks for your comment!