Over 20+ years of development using an iterative approach to development, I have noticed a common thread to the process which anyone adopting Agile should consider. The reaction from those "around the edges" is a common source of conflict. A little bit of knowledge and information prepared for them can help.
Recently, during another Agile training seminar, I was again reminded that Scrum, OpenAgile, XP, or even to some degree Kanban will cause conflict around it's edges. I also was pleased to be reminded that there is always something new to learn.
I don't intend on having a long discussion with you about the pitfalls other than to say that anyone doing Agile Development should be prepared for problems "around the edges".
As a company grows with Agile, it will inevitably show problems with systems, processes, ways of doing things, technology and other as yet unknown problems. This often happens within the first or second iteration or cycle.
This can cause an immediate dislike for Agile as it generally means that productivity first falls as people deal with the newly discovered problems.
Don't fear this! As you find problems with your processes, you will fix them. Some can be fixed immediately, and some may take many iterations to fix. The most important thing to realize is that as each iteration passes, everyone's life will improve due to improved stability of the system, less bugs, or whatever your pain.
The most important thing here is that as new problems are found, everyone resist the strong temptation to finger-point.
Focus on the processes and improving them, not those involved. This will take out the negative aspects. Once everyone knows Agile is about improvement and not blame, people will let down their guard regarding what happens and true progress can begin.
Most importantly; as time goes by, the team and the processes will become more efficient. After a while, if all goes well, the speed and lack of problems will soon surprise your stakeholders with its' efficiency.
Again, don't be surprised. If you are learning and agile approach to work, you will discover problems quickly. This is considered one of the benefits of Agile development.
That being said, I believe it is important to help yourself and educate those around the team if at all possible.
I recently did a little training session for a new team I am working with to show them the benefits and practices or developing in short cycles, and working on a Product Plan. I explained the idea of Return on Investment or "Value Drivers" (something which was new to some of them). They learned about committing to a Sprint or Cycle plan and were given a small non-technical project to do to learn these processes.
It was a project they could not complete in the alloted time and one that none of them had any experience with. It was non-technical and not related to IT. This allowed the team to focus on the processes and working together and not get bogged down in IT technical arguments and discussions.
I made sure I let the team know about the concept of Forming, Norming, Storming and Performing before starting, so they would know what was to be expected. It helped considerably with the exercise.
What was interesting to me was that during our 2 hour training, there was interest from other groups within the company and a variety of comments, but mostly the feeling that we were simply doing "team building" exercises, which is unfortunately only partly true.
Others in the company were curious about what the Team was doing. This got me thinking... It's obvious that the people around the "edges" don't know what our processes are and what they are about. This could be a reason for much of our "edge" based confrontation. Also, there seemed to be some genuine interest from others as our team is clearly becoming very efficient.
I would suggest that if you are in a situation where you are introducing Agile processes into your organization, you spend some time to educate or at least introduce those near the edges to your processes. They may not understand them or even appreciate the benefits, but they will know that you are working towards a specific way of working. Peers will have a better understanding of why your team does things "differently". For me, at least, this appears to have already helped where I am.
Other leaders in the company have been given some basic information about Agile and what it is about and some links for them to follow. It looks like it was a great idea. The more transparent we are about our processes, the less stress at the "edges" there seems to be. What a great feeling.