User Stories Driven Development

User stories driven development is great way to do agile development. No better way to get the User, Product owner, developers and QA getting engaged together into active conversation through out the development cycle. Though simple, the implementation for new organization can get really difficult. System, process and people doing traditional long detailed requirements docs driven development have to unlearn lot of old practices before adopting new agile concepts of User stories. Roles and  responsibilities of each stakeholders are always at conflict and development organizations  struggle to get it right the first time. My suggestion is get the Agile champion to infuse new agile ideas and concepts. 
Old timers will always oppose it. Product management will get their hands off from writing User stories which contain just enough details to initiate the conversation between team members. They will always crib about the time constraints. We can not blame them, as they have been trained in writing either detailed requirement docs or Use Cases behind closed doors before other team members actually get a chance see it. There are other practices which make proactive dialog between Agile team memebrs difficult. Developers have ego,  they think they can read any requirement doc and craft it into a product. QA will always test and break what developer has implemented. Real user requirements are lost in this cycle because therir is npo active feedback loop keeing them on track. Finally user get a system as per the stated requirements but not what they wanted. 
Mike Cohn’s book on User story driven development is is great read. 
Hazzan, O. and Dubinsky have posted an interesting article on InfoQ – The Retrospective Practice as a Vehicle for Leading Conceptual Change  about Agile retrospections.

Agile retrospection sessions at the end of each sprint enable knowledge sharing and continuous improvement for software development process. Scrum teams’s self-realization for needed change require a conceptual change for understanding and leading the agile iterations. Small conceptual changes at every retrospection will lead to bigger meaningful change for overall  sofware developement improvement.

Team Participation, Measurements, knowledge sharing and Implementations of fundamental actions drawn to fill these realized gap will lead to self facilitating and improving teams.