Skip to main content

Pair programming in scrum

Last post 01:29 am May 19, 2022 by Eric Lopez
8 replies
02:04 am May 18, 2022

Hey community! So one of things on our scrum team we are looking to improve on and foster a an environment of pair programming. Helping developers bring a pair programming culture into the scrum events (sprint planning). I guess for more guidance with lesser experience developers. Anyone have any input of ideas???


02:39 am May 18, 2022

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


02:43 am May 18, 2022

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. 


02:46 am May 18, 2022

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


03:06 am May 18, 2022

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.


10:53 am May 18, 2022

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.

 


11:25 am May 18, 2022

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


04:24 pm May 18, 2022

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. 


01:29 am May 19, 2022

Thank you all! 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.