"Selling" Scrum to Developers

The best way to answer questions about the benefits of events or activities is to demonstrate.

For retrospectives, are you leaving the retrospective with opportunities for improvement? Are the right people in the team working on making the improvements over the course of the Sprint? Are you reviewing those improvements at the start of the next retro? If you make the opportunities for improvement visible and transparent, and take a minute to review progress, the team should see the benefit. The same is true for outside of Scrum - any time when you are trying to improve, the best way to get buy-in is to demonstrate improvements, and also to acknowledge when improvement efforts didn't work out so well.

For Daily Scrum, I'd want to make sure that the team understands the purpose is to plan and adapt, raising concerns quickly if the plan is not likely to be achievable. I know that the Scrum Guide says that the Daily Scrum is for the Development Team, but I've had success with the Product Owner also present as an observer and to address concerns at the end (or immediately after) with the team. Perhaps there are alternative formats or techniques to ensure that the team is having an effective session.

A developer may very well be a firm believer of Scrum and in being a member of a cross-functional, self-organised Development Team, but if his annual review and bonus rely on traits of a developer who excels in only one skill and ticking off the items he's been pushed by his line manager, then the likelihood of working as a Scrum developer is slim. 

If the organisation doesn't pull that behaviour from the Development Team, then it's much harder to 'sell'. 

From the Scrum Studio whitepaper:

People often (though not always, to the frustration of managers) do what they are incented to do. As a popular saying goes, “What gets measured gets done.” Aligning objectives and measures to support the change is necessary but not wholly sufficient. But if you want people to work as a team, you have to reward them for working as a team, and you must forego individual measures and incentives.

I am facing trouble in motivating them to be engaged in Scrum Events and absorb the Scrum values

What is the root cause behind that trouble? Is it general or individual-based? Is it team-based or organization-based?  Take into account that dealing with individuals and their motivations is not an easy thing to master since people are IMHO one of the most complex, crucial elements of a scrum team, so they deserve special attention, care and subtleness.

For example, have you asked them (group or individual) whether they feel Scrum is (not) working for them? If so, why? You also mentioned you feel a lack of enthusiasm. Be open with your feelings. Ask them and watch for reactions. At the least this will disclose some insights which a Scrum Master could work on.

The title of this post is "Selling" Scrum to Developers. I see the double quotes around selling and I know what you mean :)  however, some of your people might feel Scrum has already been sold to them, and that is something you want to change. To improve the team's perception of Scrum first you need to reach them where they are.

Getting the developers in my organization to be involved in Scrum and take advantage of it is the most difficult task I've had so far.

Who in the organization actually wants Scrum to be implemented, and why?

Where would a sense of urgency for change come from, and how would it be communicated?

@Juan points an important part.  If you are trying to "sell" Scrum, you may be a part of the problem. Instead of "selling" Scrum, maybe you should be "proving" Scrum.  The questions of "why do we have ..." or "I don't see the benefit ..." to me are indicators that they don't really understand.  Each event and artifact of Scrum have specific purposes focused towards the ability to inspect and adapt. I have found that helping them really understand that has lead to better acceptance of the practices. The Scrum Guide starts the section on the Scrum Master with this statement

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

It goes on to list services that the Scrum Master provides to the Product Owner, Development Team and Organization. Every section has a similar bullet point around helping <role> with their Scrum understanding. There are also statements about facilitating Scrum events as requested or needed.  It seems like there is some need.  Maybe attending the Daily Scrum would be a good idea. As the team gathers, remind them of the purpose.  And if they start to stray, maybe a subtle comment to point it out would be warranted.  I start all Scrum Events by reminding everyone in attendance of the reason for the Event. I do this even if the team is functioning well, just to remind them. 

I have found a lot of success by helping them incrementally.  Just as the goal of agile is to incrementally deliver software product, I feel that process improvements and mindset changes are easier to learn and appreciate if done incrementally.  Celebrate small success just as much as large success. Never shy away from discussing shortcomings.  Notice I didn't say failures.  My philosophy is that the only failures are when you do not learn from shortcomings/difficulty.  That is a failure to inspect and adapt.  Those should also be discussed but are harder because if people involved really saw them as issues, they would not ignore them. But as a facilitator and agile champion, you should not be afraid to help them understand why the issues are problematic. 

So far, I have held individual chats with each member of the team in order to explain Scrum to them and what it brings. 

I only do this as a last resort. I attempt to help the entire team understand the importance of trust, openness and willing to share by having conversations about difficult things in the open. I have nothing to hide, especially around the benefits and inner workings of Scrum, so why would I have those conversations in private?  You might also find that other team members have good ways of furthering understanding to their colleagues.