This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
1. Why in many teams or enterprise the agile methods is not accepted or simply denied? i saw many projects when agile perspective can enhanced the value and accomplished the goals , but the Managers, architects and clients not accept the proposal.
2. In a "Jungle" enviroment (Team without methodology, process, code and fix) , how your book can help to move to agile side ?
Large enterprises are known for their stability. It is why people work for them, why people invest in them. A company whose operating principles are anchored in stability might have trouble adopting new methods and particularly methods whose goal is to not be more stable, but more capable of handling changes and reversals. I think it's to be expected. Some enterprises are switching, because they're seeing that some agility in the marketplace can help them hold onto an advantageous position. Some are switching because it's what other stable companies are doing. Some will not.
XP came from a more "jungle" team, as an agreement among team members on how they can find their own way and do their own best work. That's true enough not to be a "revisionist history." I suggest that you can come to working agreements on your own, and should consider the agile practices if you all agree there is advantage to them.
Interesting question. I've consulted in a good number of organizations, ranging from fairly large to small. Large enterprises are like ships, hard to steer. More often than not, we see pockets of agile in such enterprises, and usually they come from grass roots initiatives on the parts of interested teams. The nice part is that there is much about agile that you can do within a team, things that do not require the approval of the rest of your organization. The downside is that you can only go so far with such sub-team optimization before you realize the bigger problems (the ones in the rest of the organization that you can't change) are holding you back.
If you are interested in agile, and have begun practicing it, the cards can provide some positive impact. One thing is that they demonstrate that there are other people out there trying agile, that agile is real, and that there are both good ways and poor ways to approach it. Suppose someone says, "We seem to be getting off track here;" at that point you can bring out the Retrospectives card and talk about a structured way to begin addressing the issues.
We do also have a few cards that talk about why people resist agile, and as well about some of the common pitfalls and challenges. You might also visit our blog site for additional material around this topic of helping people transition to (and understand better) agile.
Both Tim and I have encountered shops where agile is mostly just a buzzword, a new set of terminology for the same old thing, or worse, an excuse for increased management "governance" (... which is really the opposite of what it should be). You don't want that! Our goal is to help you understand how to put together a solid foundation for doing agile with at least some chance of long-term success.