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

    So, I offer my final thoughts after responding to this entry by Sean Landis.  Previous entries in this series are:

    Philosophy vs Implementation


    software is hard. Developers know that.  Product owners, even if they

    understand that, still may not understand the full implications of that

    reality. Agile attempts to bridge that gap and does a pretty darn good

    job, in my humble opinion. 

    However, as with all good ideas,

    philosophy and implementation can be world’s apart.  Some people

    criticize Agile as being some sort of Utopian Ideal or non-attainable

    Nirvana.  In conversations I have had, I have made analogies to the

    essential core of social philosophies that seem to promise a lot but

    fail to recognize certain realities of humankind.  Those very

    philosophies, with noble and lofty ideals, have often failed in their

    implementation.  But, that does not necessarily mean we abandon the

    heart of those ideals.

    In software we can afford the luxury of

    pressing on toward the ideal that Agile offers without causing the

    downfall of a government or social system (at least, I hope so!).  We

    should not just abandon it because it is not perfect, has been

    misunderstood in the past or has been misapplied with abysmal results

    somewhere else. There have been tremendously successful software

    projects that owe their success to Agile and which, in my opinion,

    would not have been as successful with a more “traditional” approach.

    Be Agile With Agile


    fundamental analogy behind Extreme Programming (an Agile variant) is

    that of driving a car.  You get in the car, back out of the drive way

    and begin heading toward your destination.  You have a map, you know

    where you are going, but along the way you make necessary corrections,

    keeping your goal in mind.  Your steering drifts to the right, you

    correct; you run into a construction zone, you detour around it – all

    the while keeping the goal in mind. 

    That is a fitting

    analogy for our approach toward this broad term, “Agile”.”  Just as we

    correct ourselves along the way on an Agile project, we could take the

    same tack with our understanding of Agile itself.  Let’s learn from our

    mistakes in implementation, continue to refine our understanding of

    what Agile means, adjust our course along the way and press on toward

    the goal of writing higher quality software that serves our customers

    in more efficient and meaningful ways.


    [Original version of this was posted 1/16/2009 at]

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

    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

    back in.

    **Pitfall 10**: Too much power can be granted to the product owner when it comes to steering the product.

    My opinion:

    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.

    **Pitfall 11**:

    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.

    My opinion:

    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.

    Coaching for

    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

    its implementation.

    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

    development effort.


    In an

    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]

    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……This role can become a bottleneck

    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. 


    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


    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.


    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.



    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]

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

    In the previous two installments (Part One and Part Two), I wrote about Pitfalls 1 through 5 of Sean Landis’ this blog entry.  I continue with Pitfall 6 here.

    **Pitfall 6**: Agile teams have a tendency to focus on tactical accomplishments at the expense of strategic goals.

    My opinion: true, kind of.  This is true on all types of teams I’ve been on, Agile or not.  The place I believe this statement might be relevant to Agile is in the word “tendency”.


    first response is to play somewhat of a Devil’s advocate and ask, “So

    what?”  As long as the software does what it’s supposed to do, is

    maintainable and makes the business happy, why not leave the strategic

    thinking up to the business experts?

    However, what if a lack of

    understanding of strategic goals on the part of the developers and

    architects affects design, which in turn does affect extensibility and

    maintainability?  Now, we have an issue, and an issue to which I

    believe Agile could be prone because of many proponents’ emphasis on

    the principle affectionately termed “YAGNI” (You Ain’t Gonna Need It).


    lot has been written about YAGNI and I don’t claim to have read it all

    nor want to rehash it all here.  Let me just offer two cents and how I

    believe it relates to this pitfall.

    If we are not careful, we

    can end up practicing YAGNI as a knee-jerk reaction to

    “design-up-front”.  We must take care it does not infect our planning

    and design of software.  Very often our understanding of the overall

    strategic goals, especially from a business-value perspective, helps

    inform architecture and design. We must be careful not to overlook this


    At my previous company, we supported and extended a

    system used to help originate mortgage loans.  From the get-go, the

    system was built around the concept of a Loan Application.  Once

    committed to a design that was Loan-Application-centric (by I don’t

    know how many millions of lines of code), it became evident to the

    developers that the Loan Application really had a parent concept of a

    Loan Package.  The Loan Package could contain one or more Loan


    I cannot describe to you the incredible

    gymnastics we had to perform to retrofit the system to deal with Loan

    Packages.  Refactoring was a monumental effort that we were not given

    time to address.  To me, this was a clear example of the truth of this

    pitfall, and a clear example of how YAGNI could get you in trouble. 


    the developers known the business concept of associating multiple loans

    with a single property early on in the process (which might have

    surfaced had they know the strategic direction of the business), we may have avoided this problem.


    I don’t think Agile is responsible for this; I have seen the exact same

    problem many times over many years in a number of different types of

    shops.  This is an age-old problem, one of which Agile is actually

    trying to address.

    On the other hand, I do think a YAGNI

    mindset is very helpful, especially when practicing TDD/BDD.  If you

    work even half-way through Kent Beck’s Extreme Programming Explained,

    for example, you will see how YAGNI, when practiced with TDD, helps

    evolve a design in a simple, yet elegant way.  In that context, YAGNI

    makes sense. 

    However, I have seen proponents of YAGNI go so

    far with the concept that they kept themselves blinded to important

    issues that were just over the horizon that, when discovered, cost a

    lot in terms of refactoring, redesign, etc.  It is my humble opinion

    that too much YAGNI can be almost as bad as too much upfront design.

    YAGNI is good, but must be balanced. Achieving that balance is hard and

    very often comes only through experience, trial and error.  Part of

    learning that balance is to realize the contexts in which YAGNI makes


    Agile or not, management has a responsibility to provide

    leadership on maintaining the proper balance here and provide for a

    process by which every relevant practitioner has an appropriate

    understanding of the strategic goals the project is designed to support.


    point: the intimate relationship Agile practitioners develop with the

    product ownership team can provide quite a bit of opportunity to

    understand the strategic placement of the project simply because of the

    continual dialogue that occurs.  Inevitably, in my experience, business

    context is very often communicated as a natural part of these

    interactions.  Not always, but often.


    Short and sweet: be careful with YAGNI and understand the business your software is being built to support.


    remain a firm proponent of Agile methodologies because, in my

    experience, they work and work well – better than other methodologies

    I’ve participated in.  To me, Agile is NOT the issue.  Managing

    ourselves and the software-unfriendly human tendencies that we struggle

    with in our profession, no matter the process or methodology, is the


    [Original version of this was posted 1/12/2009 at]

    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]

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

    It is with great interest that I read articles and books that deal

    with the “ugly” side of Agile development, especially because my

    current team is in the process of beginning to implement some Agile

    processes in our environment.  The last thing we want is to see our

    adoption of Agile practices fail.  So, we are looking to take “what

    works” and implement those things gradually into a system that is

    ad-hoc right now. 

    I appreciate this blog entry

    by Sean Landis and write the following in response to and as a

    continuation of the discussion he started.

    For this entry, I will focus on Sean’s first two pitfalls:

    Pitfall 1:  Agile teams may be prone to rapid accumulation of technical debt.

    My opinion:

    true.  However, that is not the failure of Agile, per se, but rather a

    failure of the Agile community to sufficiently address this reality. 

    Agile coaches need to be cognizant of this fact (mine was, actually)

    and stress the importance of putting refactoring work into each

    iteration or sprint. 

    This will diverge from “pure” Agile in

    the sense that a refactoring story does not provide a business

    deliverable.  But, just as in traditional (or dare I say, “legacy”)

    methodologies, the business customer needs to understand the importance

    of addressing technical work that must be done in support of the final


    Maybe I have misunderstood, but isn’t one fundamental philosophy of Agile the idea

    that we adjust our activities to fit changing needs?  Heck, Agile

    itself might need to be Agile here: adjust itself to deal with the

    reality of technical debt.  Hint: take a look at Scrum.

    With that being said, here comes The Big But: part of what Agile is about is craftsmanship.  In fact I’d have to say that craftsmanship is a driving aspect of Agile and underpins some of its core practices, leading us to fantasize about the elimination of technical debt.  Principles like S.O.L.I.D., Clean Code, etc., though their constituent parts have been around in some form long before Agile, are key components of at least my understanding of Agile.  For me, it is those principles within the context of Agile that are so compelling. And these principles, practiced in concert with techniques such as Test-Driven Development and Continuous Integration, push us closer to the ideal of eliminating technical debt.  Until we reach that perfect state of being, however, we do need to address the reality of technical debt in such a way as to repeatedly and continually produce working software.

    **Pitfall 2**: Successful Agile development presupposes team members will all act like adults.

    My opinion:

    true.  However, I really think this is a selling point of Agile, not a

    pitfall (of course, it depends on your audience).  Shouldn’t we all act

    like adults whether we’re developing software, drilling for oil or

    serving hamburgers? 

    Some of the things I think acting like an adult means:

    • Letting go of arrogance, impatience and condescension. 
    • Doing what you’ll say you’ll do
    • Taking responsibility to be the best you can be
    • Making a commitment to lifelong learning and personal growth
    • Doing your best today, realizing that tomorrow you’ll be better
    • Helping others who aren’t as good, smart, talented or knowledgeable as you, without being arrogant or cocky. 
    • Taking pride in your work and assuming others are doing the same, until proven otherwise.
    • Taking pride in accomplishments to date, but being open to learning from someone who has accomplished more
    • Knowing your limitations, working to stretch beyond them but being willing to ask for help when necessary


    “suffers” from this pitfall because the world suffers from this

    malady.  The controls that other methodologies have to deal with this

    very fact of human existence are not any more effective than the

    emphasis on personal responsibility Agile embraces. 

    On a good

    team, Agile is self-correcting: the transparency required, the pairing,

    etc., all tend to place social pressure on those individuals that are

    not “cutting the mustard.”  They either get better or end up leaving

    the team because they can’t stand the scrutiny. 

    Maybe Agile is actually quite effective at making sure we all behave like adults.  Is that really a bad thing?



    really just pitching my two-cents out there for consideration.  Next I

    will throw my feeble mind at Pitfalls three, four and five.  If anything

    sparks ideas, views, opinions, contrary or not, please feel free to



    [Original version of this was posted 1/7/2009 at]

    How to Configure Selenium RC for Use In C# NUnit Tests

    When I set about integrating Selenium into my test suites, I found all the information I needed to do that with but had to hunt and peck through my google searches to find it.  So, as a point of reference, I figured I’d put what I needed to do all in one place:

    Two main activities:

    1. Set up Selenium RC server in Windows
      • Download latest Java SE from and install
      • Create a folder named Selenium under your jdk or jre bin file (example: C:Program FilesJavajre1.6.0_05bin).
      • Download latest version of Selenium RC from and extract into your newly created folder
      • From the Command prompt run the following commands:
        • cd [your jdk/jre bin directory] (example: C:Program FilesJavajre1.6.0_05bin).
        • java -jar .Seleniumselenium-server.jar -interactive
        • If you see the following messages your Selenium server is alive and kickin’:
          Entering interactive mode… type Selenium commands here (e.g: cmd=open&1=http:/
    2. Place a reference to the ThoughtWorks.Selenium.Core.dll into your .NET test assembly
      • This

        can be found under the Selenium install directory (example: C:Program


    Git ‘Er Done With Some Tests

    Now, you’re up and ready to start writing NUnit tests using Selenium in C#.  By the way, you can record your tests using the Selenium IDE and export the tests to a number of languages, including C#:


    Example Test Suite as Exported using the above:

    using System;
    using System.Text;
    using System.Text.RegularExpressions;
    using System.Threading;
    using NUnit.Framework;
    using Selenium;

    namespace SeleniumTests
        public class NewTest
            private ISelenium selenium;
            private StringBuilder verificationErrors;
            public void SetupTest()
                selenium = new DefaultSelenium(“localhost”, 4444, “*chrome”, “http://sparkystestserver:48/”);
            public void TeardownTest()
                catch (Exception)
                    // Ignore errors if unable to close the browser
               Assert.AreEqual(“”, verificationErrors.ToString());

            public void TheNewTest()
                selenium.Type(“loginname, sparky);
                selenium.Type(“password”, “mooseButt);
                Assert.AreEqual(“burp”, selenium.GetValue(“burpField”));

    Hope that helps!


    [Originally posted on 2/3/2009 at]

    Qualities that Undergird Agile/XP Development


    The six core values of XP, as elucidated by Kent Beck in Extreme Programming Explained, 2nd Edition),

    provide a strong backdrop for the principles and practices he exposits

    in the book. But while preparing an introduction to XP/Agile for my

    colleagues this week, I became intrigued by something that had been

    lingering in my subconscious. I kept feeling like something more

    fundamental was necessary for me to understand in order to be able to

    fully explain the philosophical underpinnings of XP in a way that would

    make sense to my audience.

    While reflecting on what I was feeling, I remembered something AgileJoe

    said was one of the primary qualities he looked for in a developer:

    humility. Then I remembered that Kent Beck says “the key to XP is

    integrity” (p. 159) and that integrity is defined as acting in harmony

    with one’s values.

    As part of the Tae Kwon Do training my son

    and I went through, we had to memorize something called “The Five

    Tenets”, one of which was humility. The illustration provided to us

    showed someone kicking high on a dummy target and feeling very proud of

    himself; then someone came along who could kick higher. The lesson was

    that no matter how good you are someone else will eventually come along

    who is better. Be proud of accomplishments to date, but maintain a

    mentor’s heart and a teachable spirit.

    As well, I recall

    reading about how the Jewish sages teach that even great masters can

    learn from the most novice of students if the master remains attentive

    to the gifts and opportunities each student offers.

    This was

    feeling good, so I continued down that mental pathway and set about

    trying to put together the “best of all possible worlds” list of

    qualities and attitudes that support the values XP espouses. Among a

    host of other things, I felt that Agile/XP development means:

    • Taking personal responsibility for continuous self-improvement ;
    • Appreciating and encouraging the unique talents of each team member;
    • Assuming our teammates are doing their best, unless proven otherwise;
    • Holding each other accountable for demonstrating XP’s core values;
    • Holding each other accountable for adhering to the principles and practices agreed to by the team;
    • Understanding when a team member is weak in a given area and providing support for their own self-improvement;
    • Being slow to judge and quick to encourage;


    a result of this line of reasoning, I began to feel that the two most

    important qualities of a good Agile developer are integrity and

    humility. Taking a look at each of the above (feel free to add more, as

    I’m sure I have not thought of them all), it is easy to see how some

    require integrity, some humility, some both.

    Practicing these

    things in a team setting, fosters a safe, non-judgmental environment.

    And in a safe environment, principles and practices that align with XP

    core values have an opportunity to flourish. Without these, true

    collaboration is not possible and in the end, everyone suffers.


    this cannot happen by prescription. On my last team, one of the team

    leaders once talked about more rules when he didn’t feel developers

    were switching pairs frequently enough. This caused resentment among

    some team members who felt like they were the best at determining when

    it was appropriate to switch pairing partners. That’s a tough

    situation. In the end, if humility and integrity are practiced, core XP

    values begin surfacing and situations like these are resolved and the

    team moves on.

    In my humble opinion, people who don’t practice

    these things in their own professional lives stifle Agile/XP

    development. You can’t talk Agile then criticize someone coldly when

    they ask a question; or talk badly about them behind their back.


    values, principles and practices of XP require changes in us, many of

    which fly in the face of traditional development practices and office

    political settings. XP requires an environment in which communication

    and feedback occur unhindered, in which failure is understood and

    utilized for ultimate success, in which improvement is a natural

    process and opportunity abounds. These and other XP principles and

    practices require the cultivation of an environment that is safe for

    all members of the team.

    If individual team members nurture

    these basic attitudes of humility and integrity in their own hearts and

    minds, fear (and the silence and self-defensiveness it engenders in

    team members) is minimized. This helps till the soil and provide

    fertile ground in which collaboration and innovation have a place to

    take root.


    [Originally posted 12/1/2008 at]

subscribe via RSS