Measurement and Sentiment

A good friend of mine and former colleague is working in an environment of legacy applications, with legacy developers who don't want to take part in any development practice change. He is charged with moving all of their pre .NET apps to a later and greater version of Microsoftness. They are encouraged to come along on the journey but are not really interested in changing their ways much at all.

While thinking of advice to give a friend, I came to these conclusions.

The first thing with change is to understand that it is human nature to resist it. The ones that push back are not the freaks, those of us who chase the mutations are. We are the minority but we are the ones who shape the world around us.
That is why buy-in from your team members (the pigs, not the chickens) is extremely important.

Rigorous practices is what makes an agile team. Those practices are determined to work based on two things - measurement and sentiment.

Measurement is the data that proved that a practice applied rigorously achieved a measurable increase in quality or quality or clarity or whatever your sliders are set to.

Sentiment is the buy-in to the practice by the team members. That is devs and BAs and testers and business reps and anyone else involved in using that practice to get the best results. Without buy-in, the practice should be dropped after trying it for one or two iterations.
On a new agile team with people who are feeling consciously incompetent and not believing, you can fail to gain buy-in or lose what little you had.

Without sentiment, measurement is unsustainable. Without measurement, sentiment is unjustifiable.
When I teach engineers or any member of a team a new way of doing something, I explicitly ask for buy-in. If they don't give it then I sit with them and try to understand what the pain point is that they are experiencing. Then I address that concern, beit with understanding or a different practice or explanation or discussion.
Try do this at an individual level if you have relationships already or think the discussion will build rapport or technical respect.
If it is the whole team you need to address then use a retrospective that allows everyone to air what doesn't work in a constructive setting. Self organising teams must decide what is best for them with some guidance but they must choose for themselves. If they choose then they commit as part of the deal.

Often those who suggest the ideas are the outspoken ones and the leaders of the descent anyway. Use them as a force to encourage change.