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]