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

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. 

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.

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

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.

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.

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”.


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]

This entry was posted in Agile Development, Community, Extreme Programming, I.T. Management. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

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

  1. m4bwav says:

    It doesn’t seem like Agile is very appropriate for adhoc management situations. If your on a project with 5 people from 3 companies, who’ve been hired to save a difficult deadline, there aren’t much time for someone to educate everyone on why a scrum seems cool.

    I think that Agile teams can (or cannot in some cases) be very effective but the initialization and training cost of switching to agile is immense. And I don’t think that is highlighted enough.

    Most of the time a group of people at a company read a book or something and try to create what turns out to be a mutant version of agile, with a disjointed collection of practices that sound interesting. This in turn, has little effect on their actual development process.

    It really takes an agile pro, mentoring other initiates to set the whole thing up quickly and effectively. And we all don’t have situations where this is possible.

  2. Chris Taylor says:

    @m4bwav Regarding your first point, I have not had the fortune to have to manage in that situation yet. My gut tells me you’re right. That situation calls for at least one person who can quickly come in, draw from his Agile/Scrum/XP experience, help the team regroup and create a plan that makes the most sense given the experience of the individual team members.

    Compromise will be the key in a situation like that, unless all team members are already versed in aspects of Agile. After the urgent need is met and the dust settles, there might be a wonderful opportunity for the team to look at Agile more deeply and see if its practices would make sense moving forward.

    To your second point regarding a “mutant version of agile”: I would have to concur, especially if folks rush in without taking the time learn the concepts, then to make a plan and work that plan. However, one of the neat things about Agile I have experienced is that you learn by doing. Don’t tackle all of Agile all at once. Maybe take a concept, such as Continuous Integration, read up on it then start working it. Once that is understood well and in place, start on the next. There are a lot of free or low-cost resources out there on the internet to help.

    The approach I have taken on my latest team is to introduce concepts slowly: first demonstrate and begin mentoring on TDD. Next, Continuous Integration. While this is going on we are discussing things like S.O.L.I.D. and Clean Code (ie., the “craftsmanship side” of Agile, if I could draw a fuzzy line).

    We are also discussing Paired Programming and the concept of Stories – when it would make sense to begin slowly integrating those in. And how. Once those are tackled, we’ll look at the next Agile/XP principle that speaks to us.

    From my perspective, I continue telling the team we’ll only implement a practice if it makes sense. I do that because I don’t believe dogma is healthy. Each team member’s experience, point of view and opinion are important. For Agile to work, it needs to make sense to a large majority of the team, at least. I can do this because I firmly believe that Agile, when really understood, stands up to scrutiny and, therefore, we can throw hard questions and skepticism at it. It can take it.

    So, I first ask myself, then I ask the team: does this make sense for us and why? The challenge is demonstrating that. Nicely, though, all these things typically make alot of sense to an open-minded developer, especially one who has been in the trenches a while. Once they see this stuff for what it really is and then experience it in action, it just makes sense.

    For example, once the team saw TDD and CI in action, they were drawn to it. When those processes are in place we will have a solid foundation upon which to build other practices in. And their faith in Agile will have grown some because not only will they understand it intellectually but they will have experienced the practice in real-world situations and seen how it addresses a pain point they’ve most likely had all their professional life.

    This incremental approach seems to be working well in the situations I’m in. I’d rather do it this way then run in and try to implement all of Agile all at once. That would be a mistake. Slow, steady steps seem to be working best in my case. Maybe it’s not ideal, but I think in the long run I will see a solid Agile team.

    As well, this incremental approach mitigates the cost of implementing Agile. If it’s not in the budget to hire a mentor or go to some training, a team can build their understanding by tackling one or two concepts at a time.

    Just some thoughts. Anybody have any disagreement? I’d love to hear it!

  3. m4bwav says:

    nice post, thanks for the detailed response