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…
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.
Better
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.
The
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.
I
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.
Conclusion:
For
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 http://agilecruz.blogspot.com]