The argument has been made: "We should be using an Agile software development method." And the command has rung out: "Make itso!" Now what do you do? How do you take that one-line "requirement", and make it so?

Adopting an Agile method is no different from any other change we might make to the methods and tools we use. We must determine why weare embarking on this course, choose the method that will satisfy the need mostclosely, then map out the path from where we are today to where we need to be. Then we can "make it so".

Why Adopt an Agile Method?

Before we start changing things, lets first step back and be
sure we understand what it is that we are trying to fix. After all, if therewere not a problem with the way we do things today, there would be no reason tochange. So, our starting point is the original argument for adopting an Agile method.

If there was significant discussion before the decision to
adopt was made, then the information we are looking for may already exist. If
little was discussed (or if there is no record of what was discussed), then you
will need to work with the person who suggested the change to understand why it
was suggested. Are there problems with the methods we use today? What are they?
How bad are they? Who is affected by them? Or is there the expectation that
although no large problem exists, an Agile method would allow us to improve over
our current methods? What sort of improvement is anticipated? How significant is
it expected to be? And who might be the beneficiaries of the improvement?

We also need to discuss with the decision-maker why they
decided to approve the idea. What did they envision? What benefits do they
expect? How do they think things will change as a result of adopting this new
method? And most importantly, what would be this personís definition of
"success" in this endeavor?

Of course, when we discuss these things with multiple people,
we may find that there has not yet been a meeting of the minds on exactly why we
should adopt an Agile method. In that case, we must bring the diverging minds
together (preferably in the same room) to discuss their different perceptions
and agree on exactly why we want to do this.

Regardless of what it takes, we must end up with a
clear and consistent description of the reason why we are adopting a new way of
working. Indeed, without this, we are virtually assured of failure, and some of
the major constituencies are likely to be unhappy with the end result.
Conversely, with a clear understanding of the "why" of the effort, we
are equipped to move forward with confidence.

Adopt Which Agile Practices?

Now that we know what we want to achieve, we can examine the
various practices that we could adopt and decide which of them will be
appropriate in our organization. This is a piece of the process that is easy to
miss, especially if the mandate is to adopt a specific Agile method (like
eXtreme Programming or Scrum). But even if a specific method has been
prescribed, it may not make sense to adopt all of the practices of that
method. We need to carefully consider the uniqueness of our organization and the
projects we undertake to decide which practices will fit in, and will help us in
achieving the goals we have identified.

The major areas that we must consider are:

Our organizationís culture

Our customers and how they prefer to interact with us

The types of projects we do

The tools and processes that we currently use

The strengths and weaknesses of our software-related staff

Organizational Culture

All of the Agile methods are built around the concept of a
self-directed team. The development team is not told what it will do and when it
will be done by. Rather, they are given broad direction about goals, and then
they work with the customer to determine how to reach those goals.

If your organizational culture is build on a "Command
and Control" style of management, then many of the practices of the Agile
methods will represent a serious challenge to the organization. The managers
will need to alter their management methods and adopt a more collaborative
relationship with the development teams. This is a very difficult transition for
many old-school managers to make, and could be a significant stumbling block to
the successful adoption of any Agile practices.

Another organizational issue revolves around planning and
commitment making. If your organization expects plans and requirements to be
finalized up front, and then adhered to throughout the project, then the Agile
methodsí incremental planning and requirements definition practices will be
problematic. The Agile methods assume that we cannot know all of the things that
will come up during the project, so they plan and define requirements at only a
high level in the beginning. Then they add detail and revise them incrementally
throughout the project, always keeping the projectís broad goals in sight.

Examine the practices that you expect to adopt, and for each, determine the extent to which it can be implemented given the realities of yourorganizationís culture, and the benefits you anticipate can be reasonably expected to accrue.

Customers

All of the Agile methods expect significant participation of the ultimate customer of the project with the development team throughout theproject. This is often accomplished by having a representative of the customerworking closely with the team on a regular basis. (Different Agile methods carrythis model to various extremes Ė with eXtreme Programming being the most extreme.)

How active are your customers in your projects now? And more importantly, how readily would they increase their participation if you askedthem to? Most customers have only limited resources to devote to the project,and any significant increase in interaction could represent an obstacle to them.Would your customer be able to commit the time and effort that the Agile practices expect of them?

Another consideration is the details of your contract with your customer. If you are developing software under contract, then the rules forinteraction may be carved in stone and essentially unchangeable. Even ifchanging the rules of engagement were possible, would your customer be willingto do so? Often, companies use contracts to protect themselves from theorganization they are contracting with. If your customer takes this view, thenthey may not be interested in collaborating more closely with your development team.

Examine the practices that you expect to adopt, and for each, determine the extent to which it can be implemented given the realities of yourcustomers, and the benefits you anticipate can be reasonably expected to accrue.