there is no doubt that agile practices specially scrum is pretty popular these days. This is not because scrum is something funky to have but rather because it really works and works very well. i know what you are saying now… 
you would be saying but hold on i have seen some companies/projects which started to switch to scrum but they all ended up in tears and had to leave it half way.
well i don't deny that. during my career i have been lucky to see some of those projects and i agree with you. but you know for me they all failed because they simply didn't know themself neither did they know scrum. i mean they didn't know their team culture –strengths and weaknesses-. They did not know how to bend the scrum practices to fit into their team culture either.
i believe shifting to scrum is like getting married. you think you already know how you are going to deal with it but don't consider the fact that it’s total mind shift. specially in software industry up until few years ago everybody was pushing for ultra extra process/documented oriented methodologies like waterfall. and we spent a lot of time learning about all sort of documentation. You have to understand that adopting scrum is not one way adoption and is rather a two way one. meaning you need to bend scrum a bit to adopt it your team culture and you also to bend the team culture to adopt the scrum.
The team which fail to adopt scrum are the ones which go by book and start enforcing everything written in a scrum book the way they were imposing CMMI level 3 processes. the point they were missing was that those books were not holistic and they were just a set of guidelines. the people in charge missed the point that it cannot be done over a night. and they have got to shift gradually.
if you are planning to shift to scrum i would suggest that you first start by teaching the team about scrum. tell them about the values it add and tell them that it’s a total mind shift from what they are doing. i am sure you will be getting comments like “For me agile/scrum is just like waterfall with shorter iterations” make sure you clarify with the team that IT IS NOT.
Then you need to start picking up the scrum practices which are easier to adopt and less challenging like daily stand ups, shorter iterations. give it a go for a while and once the team feels comfortable with these. start adapting the other things like organized backlog review, proper planning meeting.
The next step would be pushing the sprint commitment to the team members. make them understand that if the team commit to something for a sprint they don't have any choice but finishing it as a team.
i would say this is the trickiest of all. because you would have to deal with cultural, technical and process related issues in this regards. Some developer simply don't get it that they have got to honour their sprint commitments and they keep coming up with excuses. you’ve got to fix this.
Then you have to decide how you are going to deal with the Acceptance testing. do you want to do it in the same sprint? do want you want to let the QC team to stay one sprint behind the dev team? or do you want to treat them as two different teams? unfortunately there is no recipe for this and you’ve got to see what works well for you.
The technical challenge you are going to have here is about writing a testable code and writing automated unit tests for the code. you have to note that having automated unit test IS A MUST in a successful scrum project. for me there is no excuse not to write unit tests. well i am not saying to start with TDD but whatever development methodologies you use, you need to write testable code and write unit tests for your code.
writing testable code and unit tests is something that %99 of the developers think they know it but may be half of the actually know how do it.
To write a testable code there are couple of patterns/concepts which are absolutely vital. for example separation of concern, dependency injection, MVC, MVVM etc. make sure you get enough training materials for your developers to understand these patterns/concepts.
a Few years ago i used a technique which worked well for my team. basically i told my team to code without user interface and leave the user interface as the last task in each user story. so they had no other way of testing their code other than writing unit tests. that worked well. for another team of mine i tried to show them that unit testing not only improves the code quality but also saves the developers a lot of time. like when they wanted to test a booking system they had to fire up the whole application fill out a few forms to reach to the booking page and then test what they wanted to test in that page. Ok if something was wrong they had to do it again. i showed them how they could automate the whole thing in unit test once and run the quickly whenever they want. this trick also worked pretty well.
Now i encourage most of the companies to start adopting agile practices. and i am sure everybody will benefit from it. A very good example of adopting scrum is my current employer. The PMO office has done a very good job on bringing the scrum into the company with no dramas.
