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

This is the last of a five-part series (sans conclusion) I’ve written in response to this entry by Sean Landis.  Previous entries in this series are:


format I have been following is to list the primary pitfall, then toss

out some ideas of my own.  Without further ado, I’ll just jump right

back in.

**Pitfall 10**: Too much power can be granted to the product owner when it comes to steering the product.

My opinion:

Not a pitfall at all. The product owner MUST steer the product.  If

there is too much power in the hands of one individual regarding what

the product does, that is a business issue not a development issue. 

The product owner knows their business and what they need. 


checks and balances regarding how a business operates and how its tools

need to behave is not up to the development team.  Yes, we should be

“partners” with the business to help provide technology solutions that

fulfill a business need. But, we should not be the traffic cops of a

business process, or lack thereof. 

Accountability is not

erased in Agile development (in fact, one could argue accountability is

enhanced); just the methods by which information is shared and revealed

has shifted somewhat.  If this pitfall displays itself on an Agile

team, it would be hard to convince me the issue did not exist under a

different process, as well.

**Pitfall 11**:

Agile is too programmer-centric leaving it unclear how to balance work

across an organization. There is a need for better documentation and

coaching for non-development participants.

My opinion:

I agree and disagree that this is a pitfall of Agile.  In Agile all

interested teams are to be intimately involved in the development

process all the way through.  Yes, this means a lot of people spending

time in the development lab (or I.T. department) but a truly Agile team

is composed of interested members from all affected disciplines, not

just developers.  If business users, product owners, business analysts,

etc., are not involved along the way that is a result of not properly

implementing Agile, not Agile itself.

Coaching for

non-development participants is a responsibility of the Agile coach,

manager, architect and, yes, even individual developers.  If this does

not occur, again, it’s not because of Agile. It’s due to a breakdown in

its implementation.

Documentation IS a real issue for some

teams.  Since having started in Agile development, I have not had to

address this problem because my business partners have been satisfied

with “just enough” documentation, so I have limited input to this very

real difficulty others face.

What I can say is that Behaviour-Driven Development (BDD)

is an area to explore in terms of its attempts to shorten/close the gap

between requirements gathering and implementation in code.


does not eschew documentation, however.  And I think that is one

additional misunderstanding.  On my teams we still use UML, use cases,

wire frames, etc.  It’s just that the expectation of where the final

repository of all the information resides shifts to the xUnit test

cases and the actual code.  Not all business management is comfortable

with this and I wish I had an answer for those struggling in this area.


hope would be that if the product owner, upper management, or whoever

is driving the need for something such as an IEEE Software Requirements

Specification, will work at understanding the pros and cons of their

stance, be willing to relax their position for the good of the project

and work at developing a relationship of trust with the development

team such that documentation enhances, rather than hinders, the

development effort.


In an

earlier post, I spoke about how Agile developers must act like adults

(then I went on to layout some thoughts on what I really mean by

that).  In reality, all participants in the process must do that. 

Product owners and business partners need to understand Agile core

philosophies and be willing to adopt them.  It is for their own good:

they will get better software than if they don’t.

Even though a

lot of Agile practices focus on the technical team, Agile really is a

social discipline that encompasses everyone with an interest in the

final product.  When the product owners can understand how important

they are to the success of a project, I know the divide between “The

Business” and “Development” can be bridged.  I’ve seen it happen.


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

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