Pairing is Sharing
•1 like•699 views
Report
Share
Download to read offline
Talk delivered at Tampere Goes Agile 2015. An experience report moving from someone who won't pair into someone who found strong-style pairing to be more fun way to pair.
![[1] 20081021 Personality Development and Small Group Activity - Bhoj Redd...](https://cdn.slidesharecdn.com/ss_thumbnails/1-20081021-slbvp-sga-for-1st-yr-studs-21s-1227446894608003-9-thumbnail.jpg?width=384&fit=bounds)
More Related Content
Similar to Pairing is Sharing
Similar to Pairing is Sharing(18)
More from Maaret Pyhäjärvi
More from Maaret Pyhäjärvi(20)
Recently uploaded
Recently uploaded(20)
Pairing is Sharing
- 1. Pairing is Sharing Maaret Pyhäjärvi Email: <maaret@iki.fi> | Twitter: maaretpMaaret Pyhäjärvi & Llewellyn Falco Nimeä | Attribution (Finland) http://creativecommons.org/licenses/by/1.0/fi/ http://creativecommons.org/licenses/by/1.0/fi/deed.en
- 2. Meet Ru Pairing between experts is different Pairing with someone who knows how to deal with you is different Pairing on chosen tasks is different
- 3. Alexandra & Era of Pair Testing on Two Computers Shared tasks done side by side teaches differences of approaches Sharing as we go vs. Debriefing at the end
- 4. Willingness to try new things Planning to evolve our strategies Dealing with setback Feeling about being wrong MINDSET See: Carol Dweck FIXED Static, like height Look good Avoid Defines your identity For those with no talent Helplessness GROWTH Can grow, like muscle To learn Seek and embrace Provides information Path to mastery Resilience Ability Goal Challenge Failure Effort Reaction to challenge
- 5. Learning to Pair On tasks that mix novice and expert Specific style of pairing: strong- style Realizing pairing is a skill
- 6. Strong Style Pairing “For an idea to go from your head to the computer it must go though someone else’s hands” *http://llewellynfalco.blogspot.fi/2014/06/llewellyns-strong-style-pairing.html
- 7. Learning about myself Rewarded as an individual contributor Unlearning ownership of ideas and contributions
- 8. Quality
- 9. Quality Getting the best out of you (not the most)
- 10. What Testing Gives Us UnitTesting ExploratoryTesting SPEC FEEDBACK REGRESSION GRANULARITY GUIDANCE UNDERSTANDING MODELS SERENDIPITY Testing as artifact creation Testing as performanc e
- 11. Deliberate Practice by Remote Pairing
- 12. My Team “Introverts suffer with social practices” “I get more done alone” “I could try pairing (but not with you)” “Back to kindergarten with mob programming” “Ask if you need anything” “Many things need to progress” “Maybe for training purposes”
- 13. * http://visible-quality.blogspot.fi/2015/09/my-first-full-day-of-mob-programming.html That would’ve been a nasty one to find later
- 14. Explaining is not Experiencing Co-creation vs. Collaboration
- 17. Thank you. @maaretp (please connect with me through Twitter or LinkedIn)
Editor's Notes
- Pair programming is a core agile technical practice. Many people still have reluctance to pair, pair only with people they choose, only on specific types of tasks or only in case of emergency. I am one of those reluctant people pairing selectively. This talk is about deliberate practice in building up the skill of pairing to allow pairing to take one’s skills on other activities to a new level. In this session, you will learn about my different stages of pairing and lessons picked up as a testing specialist. The talk goes through a growth patterns from pairing with peers (other testers) to pairing and mobbing with developers, from traditional style and side-by-side work to strong-style pairing and to pairing on both testing and programming activities. Join me on my journey to realize that explaining isn’t the same as experiencing. Pairing is sharing on a different level, but to make the ride smooth, there’s skills to develop and styles to consider.
- “there’s a process of knowing” – learning Does not give as regression; serendipity (safety against things happening randomly) / unwanted serendipity events. This is what it is and what it could be. There’s a direction to it, not just statement of what it is. Coaching is not just feedback, it’s pointing them to the right way. Safety. EXPERIENCE (the verb) rather than facts ; emotions over facts. REACTIONS. HISTORY, Lessons learned, checklists. Modeling. UNDERSTANDING – where you start (knowing the thing (code & environment), knowing the user, knowing the problems, knowing the developers (how to help them and what they do so that you can efficiently test), knowing the hackers (weird use cases outside common ‘have you tried reading it upside down’) , knowing all stakeholders, knowing the business priorities) Uncovering things I cannot know, giving the application a change to reveal information for me. This allows you to know things.