As more and more people move towards adoption of agile practices, they are looking for guidance and advice on how to adopt Agile successfully. Unfortunately many of the questions they have such as "Where do I start?" "What specific practices should I adopt?" "How can I adopt incrementally?" and ";Where can I expect pitfalls?" are not adequately answered despite the fact that many of us know the answers to these questions.

There are currently three types of answers to these questions: 1) read so-and-so's methodology book that refers to an entire process—usually a cohesive set of practices; 2) read articles A, B, and C  to learn from 'war stories' of companies who have successfully adopted; or 3) a very honest, "Well it really depends on your team's circumstances and you might want to hire a consultant to help you out."

We can do better than that as a community! In this article I present one way to share our knowledge that is more specific than full methodologies and processes, more general than war stories, and will help new Agile adopters get beyond "It Depends!"

Introduction
This article is about the issues that need to be addressed to successfully help adopters of agile practices. It is good to step back and recall why we—the agile community—are practicing software development differently. We are doing so because we believe in delivering value to our customers as quickly and efficiently as we can by building better software. Given this overall goal, how can we help those who want to adopt one or more agile practices deliver the most value to their customers?

The first thing needed to help agile adopters accomplish is figure out which practices they should adopt and in what order. Once they have made that decision, they need to understand how to adopt each practice since describing a practice does not necessarily guarantee using it successfully to its full capacity. Finally it would help to know how other development teams have adapted these practices in the past to suit their environments, as guidance on these teams' adaptation strategy.

Choosing Practices To Adopt
The days of quot;thou shalt do all twelve practices of XP to be considered agile are long gone. Practices are adopted and adapted on an individual basis successfully. However, there is a slight problem: many times the people deciding which practices to adopt don't have any agile experience. This means that their decisions are based on their personal experience with different development practices.

Unfortunately, because they lack personal experience, they may lack the deep understanding that comes from using the practices to decide if they really are applicable to the current environment. Catch-22—Which is probably why many have suggested doing all the practices first and then choose to drop and/or change the practices when you have experience.

These people need the information to make the appropriate selection of practices. In true agile fashion, we should tie the agile practices to the business value they deliver. From there, we can decide what business values are most important to our customers. Then, we can use that information to pick our practices. This is something that our community must agree upon in order to say "To reduce time to market focus on practices A, B, and C" as naturally as we currently say "Test-driven development produces loosely coupled designs and code."

We are not there yet but Figure 1 provides a possible start.

What we see in this table is a set of business values and the corresponding clusters of practices and individual practices that help improve that set. Doesn't this seem useful to a team adopting Agile methods?

Another way to look at the same problem is from a smells standpoint. That is, what current pain symptoms is the team having? Those smells can also be mapped to practices (and clusters) just as we have mapped business value to the practices (and clusters) in the table above. Here are some smells that you may have seen in your environment:

• Quality delivered to the customer is unacceptable.
• Delivering new features to the customer takes too long (having trouble keeping up with competitors).
• Features are not used by the customer.

And here are some other smells that are not directly related to business value but can be easily mapped to the values important to the company:

• Us versus them.
• Customer asks for everything including the kitchen sink.
• Customer–what customer? Direct and regular customer input is unrealistic.
• Management is surprised–lack of visibility.

If the above mentioned smells are mapped to agile practices, they can be used to decide which practices should be adopted and why. Couldn't they also be used to figure out whether a practice is effective? For example, the team has decided to adopt Automated Developer Tests to address the smell of "Quality delivered to customer is unacceptable." After a release they should verify that the quality being delivered to the customer has improved. If the quality has not improved, then the team should either modify the practice or drop it because it did not have its intended effect. Practices should only be adopted for the business value they bring.

Adopting and Adapting a Specific Practice
Now, suppose the team has already decided on what practices to adopt from the information above, what is the next step? The following questions should be answered explicitly. If they are not answered explicitly the team will find itself answering them implicitly as it stumbles along. For the set of questions below assume that the team will adopt Practice A:

1. Where does Practice A fit within an adoption strategy? Does it come first? Do we introduce it a few months after getting warmed-up with other practices?
2. Which development practices are related to Practice A? Are there any prerequisite practices for Practice A to be effective? Is Practice A a prerequisite to other practices? Is Practice A a part of a cluster of related development practices that have a value as a whole much greater than the sum of its parts?
3. Should Practice A be adopted in stages or in one step? Are there any special mechanics to help adopt Practice A?
4. Are there any pitfalls to be wary of when adopting Practice A? Can something go wrong? What does it look like? What does it smell like? What are the symptoms when Practice A goes wrong?
5. Are there circumstances where Practice A should not be adopted?
6. Can Practice A be adapted to other forms without changing its substance? What is its substance anyway?
7. Are there any assumptions about values shared by the team that are necessary for Practice A to be effective?
8. Finally, consistent with the spirit of Agility, what business value does Practice A bring to a development team?

All of the above questions matter. All of the above questions should be asked when a team decides to adopt a development practice. Some of the answers to these questions are far from obvious–that';s where consultants like me make their living. However, most of these questions can be succinctly answered when a practice is well documented in pattern format—or so I claim.

There are also clusters of practices that work very well together. So well, in fact, that the business value delivered by a cluster is much more valuable than the sum of the values delivered by its parts individually. The most notable of these clusters is Test Driven Development (TDD) which is made up of Automated Developer Tests, Refactoring, Continuous Integration, and Simple Design. Adopters need to be made aware of these sets of generative practices; there are many more than just TDD.

Putting Patterns, Smells, Business Value and Clusters Together
So how does this help me adopt Agile practices?  With the building blocks at hand–the Smells, Practices, and Clusters of practices, it is possible to tailor agile adoption in a step-wise and iterative manner.

1. Start with an evaluation of the status quo–what is being done well and what needs improvement.
2. Map the areas that need improvement to one or more Smells.
3. Prioritize the Smells and pull the first one off the list.
4. Check the Practice Patterns that address the Smell in (3). Read them and read their related clusters.
5. Depending on your environment, choose one or more of the patterns in (4)–maybe even an entire cluster. Use the advice in the patterns chosen to start adopting those practices.
6. Periodically evaluate that the Smell in (3) is indeed getting addressed by the practice being adopted. Adapt the practices for your particular environment.
7. Go back to (1) and improve your software development process some more!

Adoption should be iterative and always goal-oriented. The objective is to alleviate the Smells currently present by adopting and adapting the applicable Agile practices. The patterns are starting points. Use them with a modicum of disrespect. As you gain experience, adapt the practices to fit your needs.

Whether we answer these questions with patterns or another format is irrelevant. What is relevant is that these questions that an adopter is faced with are answered at a per-practice level in any format. We, as a community, have the answers to these questions. 

About the Author
Amr Elssamadisy is currently a Principal Consultant at Valtech (www.valtech.com). He considers himself a developer but has also worked for consulting companies since 1999, so maybe an outgoing, people-oriented, developer is a better description. He has been working professionally as a software developer, architect, manager, consultant, etc... for over 12 years helping build software systems in C++, J2EE, and .NET. His first agile development project was a large project XP effort in 1999 where he had a chance to work and learn from some of the best in the field. Since then he has lead, participated, and guided teams in several large and small agile development projects in both the .NET and J2EE worlds.