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!"
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