This question was raised last night on the Scaled Agile Framework (SAFe) community forum. It’s a common refrain: How do we encourage people to break existing patterns and learn new things (especially when they’ve been successful for so long.)
Here’s what I said:
Senior engineers (and most people) need to recognize the value in adopting a new practice (tool, framework, etc.) before they’re willing to risk their persona (so to speak) using a new ____ in front of everyone else. There’s plenty of evidence to affirm the value of TDD and BDD as value-add practices when introduced properly and supported effectively.
If possible, identify a willing candidate and partner with her (or him) to develop an adoption plan for the wider audience (of senior software engineers.) If you can’t find a partner, consider partnering with someone outside your team (program, or organization) who has proven TDD and/or BDD successful or is willing to take this journey with you. Plenty of (proven TDD and BDD) resources/people can be identified online (and many people want to help the rest of us progress in our careers.) SlideShare, YouTube, etc.
Review your adoption plan with whomever needs to approve this experiment (training, coaching, mentoring…whatever you can afford, even if limited to on-line videos and shared books) to ensure you’re not impacting anything else, planned or in progress. The plan should emphasize that these are professional development improvements (AKA, skills that improve the ability to deliver solutions at higher levels of quality and in less time; aspects that appeal to management, customers and development teams.)
Model these changes in your product backlog and pull the appropriate activities into your Sprint backlog(s.) Ensure that everything associated with your plan is visible (to the entire community.) Perform this modeling with everyone on the development team(s) and, if possible, with management (at least for the product backlog work) to endure collective ownership (of these changes.)
Share outcomes and experiences at Sprint Reviews and discuss (the same) at Sprint Retrospectives. Consider using Brown Bag Lunches to broaden your audience (and engage more senior software engineers from other parts of the organization and additional management representatives, too.)
I’ve found this approach works for many forms of institutional change when we have to start small, prove our worth and gain credibility, adherents and momentum.