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
Pitfall 10: Too much power can be granted to the product owner when it comes to steering the product.
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.
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.
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.
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
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
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 http://agilecruz.blogspot.com]