No approach is foolproof. All require the people using them to be motivated & interested in change. At Disciplined Agile we look at failure of adoption quite deeply. The key is to believe the failure was not caused by a lack of motivation of the adopters but by improperly designed guidance. You cannot learn from failure by blaming someone else.
Highy motivated teams fail in their Agile adoption for many reasons but the ones I see most are:
1-Using pre-set practices which don’t suit the people adopting them
2-no theory explaining why these practices are appropriate
3-No method provided to adjust these practices to help the team improve and even transcend them
4-An insistence that not using these practices means you’re not following the adopted approach – this creates a psychological barrier to adopting more suitable practices
Initial motivation is often destroyed by the frustration that comes from a difficult, even inappropriate start, with little guidance on how to improve what one is doing.
DA believes people are smart enough to decide what works for them when they are provided some core insights. We never blame the adopters for lack of motivation.
Let me be clear, I am not "bashing" Scrum. (See Is it “bashing”, “criticism”, or “negative feedback”? https://bit.ly/3hLVEJK ) I am wanting to provide an alternative to those experiencing challenges in adopting Scrum whose failures are often attributed to being due to their lack of motivation. I have never liked this and I believe it unjustifably demeans the teams. A day rarely goes by where I don't see some consultant asserting this. If we had a professional consultant creed I believe it should include "I will never blame my client for their failure in adopting my approach." Doing so makes it impossible to improve one's approach. I have seen many teams of motivated people struggle with their adoption of Agile because they have been told that Scrum equals Agile. It does not, it's only one way of adopting Agile. If a Scrum proponent disagrees with my assertions, I invite you to have a discussion with me about these points (this does not include a discussion about me). My motivation is to help people struggling. I started talking about these issues in 2005 while I was still promoting Scrum. I am fine that the Scrum community doesn't want to attend to these concepts, but it shouldn't expect me to be quiet about them.