Pair programming in scrum

Are elementary hygienes in place, such as a Definition of Done which the Developers already commit to and achieve in a test-driven manner?

So, as far as DoD are in place. But we wan to live more into a test-driven environment. But tbh we are not there or have organization toward that. 

We use Acceptance criteria instead of focusing DoD. If that makes sense. 

Practices like TDD/BDD are a commitment to quality, and hence may reasonably form part of the DoD itself. My advice is to put the establishment of a good DoD first. The Developers will then have a consensus view of the quality commitment they are making, and something to self-organize and potentially pair around. For example one Developer in a pair may author a test while the other implements the functionality...a practice which might then also be instituted through the DoD.

Great advice about starting with the Definition of Done. Definition of Done and Acceptance Criteria are different. DoD is for your Product Increment, where as AC is functional test criteria unique to each Product Backlog item.

I've worked with Scrum teams who leverage pairing, and one team went through 8 or 9 different adaptations of how they do it. They originally started out pairing on every PBI, and since their PBIs were small (a day or less), they switched pairs every day. They would discuss and inspect how pairing was working in the Sprint Retrospective, and sometimes adapt. During their journey they discovered that it didn't always make sense for them to pair on every PBI.
They also discovered physical equipment needs (dual monitors, stand up desks). Covid hit and everyone was now working from home. They had to inspect and adapt again on how to do this virtually.

Lastly, as a Scrum Master try asking the Developers for ideas, as it is not the job of a Scrum Master to tell them how to do it. It doesn't have to be perfect right away. Encourage experimentation, use the Sprint Retrospective to inspect and adapt pairing. Your risk of it not working so well is limited to just that Sprint. Rinse and repeat.

Thank you both for great advices. We are continue to try different things and adapt! Thanks again! 

In my early days, I had a team that decided to do pair programming.  The team had a Definition of Done but it was very weak and didn't really provide any safety.   Their attempt to pair ended up failing.  I facilitated a day long post-mortem on the experience.  The first thing that came to light was that the team had a difficult time knowing why they were pairing on most of the work.  They said it just seemed like there were two people talking a lot while each one of them worked independently.   This was because they didn't really understand what pair programming is.  

We tried again after the entire team had taken the same online courses on what pair programming is meant to accomplish.  However, once again it did not go well.  The reason this time was determined that each person had a different idea of what it meant to complete work and when the work was integrated into an increment, the quality suffered.  This lead to some serious refinement of our Definition of Done.  

After that was done, the team became very successful with their pairing.  In fact they started to help other teams become better.  The first thing that they suggested was that every team refine their Definition of Done to guide them all in a common understanding of what has to be completed.  Then, they lead a couple of classes on what pair programming provides and how to properly pair.  

I have followed that model for many years now with mostly success.  I have found that not all work or all teams are fits for pair programming.  But you really don't know until you try. 

Thank you all!