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

I continue tossing my obtuse bits into cyberspace here, as a follow-up to the previous three entries:

This series is being written in response to Sean Landis’ this blog entry.  I’ll get right back to it…

**Pitfall 7**:

Agile can be hard on the product owner who has a lot of

responsibility……This role can become a bottleneck

because it is unable to “feed” the development team fast enough.

My opinion:

true.  But, pardon me if I am being too blunt: they want the product so

shouldn’t they be willing to put in the time and energy to make sure

they get what they need?  And if they are not motivated enough to do

what is necessary to support the development of their product, maybe

they ought to question the exigency of the software request in the

first place?

One of the primary problems Agile attempts to

address is the lag time between requirements and working software so

the product owner can see very quickly how the developers are

implementing their understanding of the business needs. 


that the owner take the time now to help the developers adjust to

changing business needs or misunderstood requirements than to wait 6,

12, 24, 36 months to find out the product has more problems than

solutions.  That will be much less costly, both in true costs and

opportunity costs, than waiting until The Big Day to find out things

aren’t working as expected.

Of course, it is easy to write

this.  Not necessarily so easy for the product owner to do.  This is

why upper management support of Agile is critical (it you’re working in

a larger company).  They will have the commitment and authority to

allocate the resources needed.  Remember, an Agile team consists of a

LOT more than just developers.

**Pitfall 8**: Agile is over-hyped, thus leading to unrealistic expectations.

My opinion: true, kind of. For starters, see my response to Pitfall 3 in this post


main point I’d like to make here, as with several other pitfalls, this

may be true but is not exclusive to Agile.  Rather it is a result of

how well Agile speaks to our needs as software professionals.


remember several other methodologies that, in their heyday, suffered

from the same criticism: the Rational Unified Process, for example. 

This does not mean some of their techniques were irrelevant.  Rather, I

see the hype that surrounded some of these as evidence the aims of each

methodology spoke to issues at the heart of pain in many people’s

experience with building software; and, thus, it was easy to glom on to

a new technique with fervor in hopes that FINALLY the pain point will

be eliminated. 

Let me also add that we, as Agile developers,

coaches, managers, architects, etc., have a responsibility to

realistically communicate the benefits of Agile in a way that does not

set unrealistic expectations.  Agile will hold its own if we approach

it with a level head.  Agile effectively addresses most common software

development pain points but it is NOT a silver bullet.  We must be

careful to give the proper impression when advocating for it.

**Pitfall 9**: A variation of The Blame Game can arise.

My opinion:

This is absolutely true, and I wish I had an answer for this.  The

characteristics that describe an Agile team are not always found in the

organization as a whole. 

The approach I have taken is to let

others know up front, in a non-threatening way, that if the project is

developed as efficiently as we hope, they may need some help in

adjusting their processes, too.  That way I attempt to defuse the blame

early by letting others know they might see throughput issues outside

of development.  I try to paint this in a good light: we’re all

interested in the same end goal and shifting bottle necks are natural,

so don’t be alarmed.  So far, I have avoided the blame game.



many folks, Agile turns traditional and well-loved, if dysfunctional,

processes on their heads.  We cannot forget how high the stakes are for

some of our customers and how important we are in helping them meet

their business goals.

Let us be patient as we can with the

business/product owners, working to help them understand that the

quality of our deliverable will be proportional to everyone’s

willingness to invest time in the process.  Let us be careful to

communicate clearly with the product owners and set realistic

expectations, regardless of methodology. 

And if Agile

reveals a bottleneck in a business process 3 steps removed from the

developers, isn’t that a good thing?  Hopefully, we can help prepare

our organization for that eventuality, receiving buy-in up front and,

thus, reducing negative political fallout.  I realize that is not not

always possible, but let us aspire to that Ideal and continue working

to mature the process.


[Original version of this was posted 1/13/2009 at]

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