• Part One
• Part Two
• Part Three
• Part Four
• Part Five

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]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

• Part One
• Part Two
• Part Three
• Part Four

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.

My
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]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

• Part One
• Part Two
• Part Three

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…<snip>…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.

I
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]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

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

My
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).

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

I
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]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

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]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

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]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Two main activities:

1. 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)
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
     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]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

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;

As
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]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.