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]

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