Getting Beyond "It Depends!" for Adopting Agile 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

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.