Think about the 'why' of your question. What is the goal that written communication will solve for your team, in your view?<p>This has two benefits: one, it challenges your own thinking (perhaps the underlying issue could be solved in a different way, which might be more successful); two, it gives you justification which you can use to persuade your team members.<p>See: Simon Sinek's "Start With Why". Additionally, I've found the "Hands-on Agile" Slack group to be a great community resource for this type of team-focused Q&A.
* Lead by example.<p>* Steer ad hoc discussions toward the issue tracker--whether via stories or spikes.<p>* Don't let Slack/IRC/Teams be the place decisions are made and documented. They're good tools for conversation starters and finding throw away answers, not good as a record of design and decisions.<p>* Always be steering ad hoc conversations towards outlets that provide reusable context when it becomes clear that there's something of substance. This could be steering towards issue trackers, wikis, knowledge repos, README.md files, etc.<p>* Realize that many people aren't natural writers, and accommodate them.<p>* Hire for writing ability. Find a balance and pair writers with talkers.
As with any other thing you try to encourage, it's not going to work without consensus or decision power.<p>If you have either, it should be easy to do so.<p>One easy way to push people in the right direction without much effort though is to allow people to work remotely more.
Suddenly, sharing something interesting or weird that happened to them while resolving something gets shared in writing, their aha moment gets told on the open ticket instead of around the watercooler etc.