The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I will do my best to answer the questions posted this week to give you what insight I can about Agile software development in general, and how the book - Agile Adoption Patterns - can help you make a decision if any Agile practices are applicable to your environment, and if so, help you get to the point where you are really getting valuable results. There is a good book review on InfoQ and a few readers have been kind enough to leave feedback on Amazon.com that can give you an idea how others have found value in the book.
Amr Elssamadisy<br /><a href="http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1220909336&sr=8-1" target="_blank" rel="nofollow">Agile Adoption Patterns</a>
Would like to inform that there are some rules for javaranch member like naming policy by Javaranch moderators.
one more thing is this thread is dedicated only for welcome to the book author, Its better to have your own thread (new Topic) to ask your query.. as this makes you eligible into book promotion week, here is the details.
1. agile doesn't mean that you can do anything you want, change anything anytime, and leave things undocumented. This is not agile, this is AD-HOC.
2. an agile process is just a different style of development process. But it is still a process. Someone STILL need to monitor, control, and administers it. The word 'agile' indicates that there is a level of freedom and liberty in there, but just like DEMOCRACY, when not enough control and understanding is in place, it falls into ANARCHY.
So in my opinion, the key in incorporating agile is:
1. Control it firmly. Define the rules and regulations.
2. Make sure that everyone understand exactly how the process works, what can and can't be done and ENFORCE it.
This sounds very simple, but the fact it there's a lot of orgs that tries to adopt agile thinking that agile means less overheads. Well, things don't just take care of themselves, someone somewhere needs to ensure that the development are progressing in a controlled manner, someone somewhere need to ensure that everyone is playing by the rules and things are traceable.
Probably this mistakes is not very visible on smaller project, because admit it, on smaller project it doesn't matter whether you are organized or not, following any process or not, you put a good developer in and he will be able to find his way through (after a lot of frustation...)
But try not having a firm structure of control and tracing in place on a big project. The difference will become obvious as the scale of the problem grows.
If you are using a rototiller, you are doing it wrong. Even on this tiny ad: