Part Two – A Response to “Traps & Pitfalls of Agile Development – A Non-Contrarian View”
In my last installment, I began giving my initial thoughts on this blog entry
by Sean Landis. In this entry, I will continue to toss my cookies into
cyberspace by addressing what Mr. Landis describes as pitfalls 3, 4 and
5.
**Pitfall 3**: Agile methodologies misunderstood may lead to team burnout due to an irrational culture of urgency.
My opinion:
I was already burned out BEFORE I started learning Agile (and I’m very much still
learning). I actually found Agile to be refreshing because it
recognizes our human limitations without giving us excuses to indulge
in those limitations.
The key word here is “misunderstood.”
To expect all things to be fully understood is ignorance, but to NOT
work at reducing misunderstanding is foolish.
Agile can easily
be misunderstood, mainly because the attraction to it is so high after
being introduced to it (if you’re like me). If we’re not careful, we
can become too zealous too early about its promise because it addresses
fundamental psychosocial issues most of us have faced in our technical
career. It speaks to our gut, to our yearning for something other than
the burnout, frustration, etc., we have all experienced before.
However,
as with any idea, we must take a rational approach (dare I say, act
like adults?) and carefully assess how Agile might address the needs of
our organization today. Our adoption of Agile must be measured, giving
consideration to the current processes, abilities and mindsets of team
members, the business climate we are in, etc. We should seek out the
advice and experience of others who have gone before us and try to
understand Agile in a broader context so as to reduce misunderstanding
and minimize the duration of unrealistic expectations.
Additionally,
I agree that an “irrational culture of urgency”, is a reality in Agile
development, but think this is due to the natural human tendency to NOT
do what Agile says to do: adjust development load up or down based upon
actual delivered software in each iteration/sprint.
When we
are not allowed to adjust as we go along, we diverge from Agile. My
experience is that I had less stress working on a highly efficient
Agile team than ever before. And there were times we could not adjust
– we just HAD to get it done due to business constraints. However,
I’ve worked more long hours on traditional teams than on Agile teams
due to the fact that our enterprise team worked hard to manage along
Agile guidelines. It really did work.
**Pitfall 4**:
Agile requires more team and individual discipline, commitment and
openness than a dysfunctional organization may be able to bear.
My opinion:
true. I think part of this stems from misunderstanding on the part of
all or some participants. And this also goes back to the issue of
acting like adults.
However, I don’t think working in a
dysfunctional organization should preclude us from adopting some Agile
practices. Again, we need to keep in mind the capabilities of our
organization. We may not be able to adopt Agile hook, line and sinker
right off the bat. But, we could incrementally adopt Agile practices
that make sense and that our other team members understand and have
bought into. In my experience, some Agile adoption has been much
better than none.
I very often must take a long-term approach: my company
does not have to adopt all Agile processes today (however, if it can, that would be ideal). Over time, more and
more Agile processes will make their way in but ONLY as they make sense
to the entire organization. Zealous preaching and legalistic
assertions against those who don’t understand or agree will make things
worse than being good-natured and making a case for Agile, patiently
addressing contrary concerns. Yes, there is a need and a drive to adopt all Agile practices in order to be “truly agile”. However, we can shoot ourselves in the foot if we don’t have patience and, thereby lose the “war” for Agile in our enterprise by turning those who are skeptical against even the hint of Agile. Remember: honey attracts more bees than
vinegar.
We may not get everything we want with this approach
(then again, we might!), but in a contrary environment we will usually
get more with this approach then if we don’t display humility and a
willingness to compromise.
Let me not be misunderstood though: even if we night need to take an incremental
approach toward adopting Agile, we must not lower the bar in terms of
what defines Agile. Here is an important post to keep in mind along
these lines: Agile: Is, Is Not, May Be by Ron Jeffries.
In the end, if we’re really
stuck in a situation in which all contrariness squashes our attempts:
well, that is quite a pickle. It does happen. Agile may not be for
every organization. We are then left with the task of deciding how
important Agile is to us and making the difficult decision to stay or
move on, frankly.
**Pitfall 5**: The high visibility on agile teams causes poor performers to stand out.
My opinion: absolutely true. Agile takes courage.
I
believe this aspect of Agile is a good thing. If we are to behave like
adults, poor performers should be discovered and provided the
opportunity to grow. And we, as their team mates, need to be patient
and understanding of their situations.
This does not mean
that we abide by someone who is intentionally lazy or unwilling to
learn; however, we all have our own unique strengths and weaknesses.
It is incumbent upon all team members to be understanding of the
weaknesses of our team mates and to encourage full exploitation of
their strengths. We should be realistic about what each of our team
mates can accomplish, but not become complacent, either. We must hold
the bar high, encouraging our team mates to reduce their weaknesses and
capitalize upon their strengths.
I tell my son I am not
interested in his grades so much as in whether he doing his absolute
best. If he is getting straight A’s and not doing his best, I will be
concerned; but if he is getting straight C’s and that is his best, I
will be pleased. Either way, I am going to work to help him achieve
more. Yes, grades do count, just as deliverable software counts. The
issue is how he get there given the fact we all are human.
I
think it is important that each one of us, when deciding whether a team
mate is not cutting it, ask ourselves what is really important. Maybe
our career goals are higher than someone else’s and therefore we pump
out more code, read more books, write more blogs and understand more
than a coworker. That doesn’t necessarily mean that coworker is lazy
or not able to write software. It may just mean that they have other
things in their life that provide meaning to them in the same way
coding does to us. Maybe their code is ugly to us. Well, how
important is the ugly code in the grand scheme of things? Sometimes,
it really does matter. But, sometimes it really doesn’t. (1/15/2009 UPDATE: I am reading Robert Martin’s Clean Code and must say that I am rethinking this statement. Nevertheless, the heart of what I’m saying remains.)
So, given the scope of all of our lives and existence, what is really important? Having lost a good friend
recently drove this point home again for me. Sometimes we worry about
things that really are not that important in the context of our entire
lives and society.
For me, what my boys think of me and the
impact I can make on their lives are more important than whether I can
code as good as the next guy. I’ll still work to become better at my
craft; but, given a choice to go fishing with my son or learn another
design pattern, I hope you’d understand that I’ll be buying night
crawlers at Walmart quicker than you can say “Dependency Injection”.
Conclusion:
As
you might be able to infer, the last two pitfalls above strike a
particular chord with me and I am sure there is much that we can debate
regarding them. Personally, I stress humility, integrity and a
servant’s attitude over arrogance, absoluteness and condescension. I
think life is much richer and more fulfilling when we are less
judgmental and more considerate of others points of view, experiences
and uniqueness.
[Original version posted 1/8/2009 at http://agilecruz.blogspot.com]