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

Chris Taylor - 10 February, 2009. It was a Tuesday.

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

Philosophy vs Implementation

Developing

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

The

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 http://agilecruz.blogspot.com]

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

Chris Taylor - 10 February, 2009. It was a Tuesday.

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:

The

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.

The

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.

Agile

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.

Conclusion:

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 http://agilecruz.blogspot.com]

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

Chris Taylor - 10 February, 2009. It was a Tuesday.

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.

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.

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]

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

Chris Taylor - 10 February, 2009. It was a Tuesday.

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

fact.

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

Applications.

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.

Had

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.

However,

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

sense.

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.

Last

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.

Conclusion:

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

issue.

[Original version of this was posted 1/12/2009 at http://agilecruz.blogspot.com]

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

Chris Taylor - 10 February, 2009. It was a Tuesday.

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.

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.

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

Conclusion:

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”

Chris Taylor - 10 February, 2009. It was a Tuesday.

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

product.

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

Agile

“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?

Conclusion

I’m

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

respond.

[Original version of this was posted 1/7/2009 at http://agilecruz.blogspot.com]

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

Chris Taylor - 10 February, 2009. It was a Tuesday.

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:

Set up Selenium RC server in Windows
- Download latest Java SE from http://java.sun.com/ 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 http://seleniumhq.org/download/ 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:/
    /www.yahoo.com)
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
  
  FilesJavajre1.6.0_05binSeleniumselenium-remote-control-1.0-beta-2selenium-dotnet-client-driver-1.0-beta-2ThoughtWorks.Selenium.Core.dll)

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
{
    [TestFixture]
    public class NewTest
    {
        private ISelenium selenium;
        private StringBuilder verificationErrors;
        [SetUp]
        public void SetupTest()
        {
            selenium = new DefaultSelenium(“localhost”, 4444, “*chrome”, “http://sparkystestserver:48/”);
            selenium.Start();
        }
        [TearDown]
        public void TeardownTest()
        {
            try
            {
                selenium.Stop();
            }
            catch (Exception)
            {
                // Ignore errors if unable to close the browser
            }
           Assert.AreEqual(“”, verificationErrors.ToString());

        }
        [Test]
        public void TheNewTest()
        {
            selenium.Open(“/Home”);
            selenium.Type(“loginname“, “sparky“);
            selenium.Type(“password”, “mooseButt“);
            selenium.Click(“ctl00_MainContent_loginButton”);
            Assert.AreEqual(“burp”, selenium.GetValue(“burpField”));
        }
    }
}

Hope that helps!

[Originally posted on 2/3/2009 at http://agilecruz.blogspot.com]

Qualities that Undergird Agile/XP Development

Chris Taylor - 10 February, 2009. It was a Tuesday.

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.

But,

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.

The

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 http://agilecruz.blogspot.com]