Learn by example... your own!

I remember when I was 4 years old and was running around on the sidewalk with my hands in my pockets (don't ask why — that I don't remember!). My Mom said, "Stop running with your hands in your pockets. You'll fall and hit your head." I didn't stop, and sure enough within a minute I fell and smacked my head on the sidewalk. Now, Mom could have actively grabbed me and pulled my hands out of my pockets preventing the accident altogether, but her parenting philosophy was (and still is over 40 years later) that we would learn better from our own experiences - our own falls - than we would through pronouncements from her.

Despite what many who have met me may think, there was no lasting damage from my fall - just a scrape and resulting scab square in the middle of my forehead. Every day for the next couple of weeks when I looked in the mirror I had that scab to remind me that I shouldn't ignore my Mom's wisdom.

This philosophy repeated itself constantly through my childhood - unless you're creating mortal danger for yourself or others, a bruise or scrape were much better learning tools than words alone.

Coaching Point
You can bleat about Agile practices all you want, but there's no substitute for the team learning on their own.  I've encountered numerous teams that will do the equivalent of running down the sidewalk with their hands in the pockets:

• Long Releases
• Long Iterations
• Team members that aren't co-located
• Teams that are dispersed
• Teams that are not cross-functional
• Manual-only testing

All of these issues will degrade a team's long-term (and often their short-term) performance.  However, they don't represent issues that will truly stop a team in their tracks.

Mortal Danger
There are some parts of Agile, though, that if they aren't present or performed fall into the category of "mortal danger to yourself or others":

• Executive Support from both Business and IT management
• Product Owner Involvement, Ideally Daily
• A Backlog of work written and prioritized by the Product Owner
• Estimates performed by the people who will be doing the work
• Work in an Iteration built to "Done, Done" state
• Reflection upon the team's work via Retrospectives

This subset represents the "must haves" for any chance of success. All other practices are optional or negotiable to some extent. If a team doesn't want to adopt them, warn them of the risks and then stand back. During the Retrospectives, listen to what the team says needs improvement. Seek ways of using the practices that haven't been adopted to implement those improvements.

You don't always have to wait for a Retrospective to point out where Agile practices can help. If the team is doing the equivalent of me running with my hands in my pockets, for example not having an automated build, let them fall on their face. Someone will eventually forget to check in something new, or will check in code that breaks everyone else. When the pain of omitting the practice is right there for the team to feel, suggest adding the practice and offer any and all help. If the team still refuses, point out that they have a scab on their forehead. If they ask what that means, tell them to ask me.