Recomendados
Más contenido relacionado
Destacado
Destacado (18)
Más de William Evans
Más de William Evans (20)
Último
Último (20)
Promiscuous pairing
- 3. "Our tendency is to be interested in something that is growing in the garden, not in the bare soil itself. But if you want to have a good harvest, the most important thing is to make the soil rich and cultivate it well."
- 5. What kinds of pairing do we encourage? • Developer / Developer • Designer / Developer • Product Owner / UX Designer • Product Owner / Developer • Developer / QA • Copywriter / Designer • Designer / Designer • COO / Director of UX • SVP Sales / Director of UX
- 11. Promiscuous pairing is effective knowledge, values, and culture transfer
Notas del editor
- Designer/Developer Traditionally a single PSD, with responsive design and a mobile first approach it no longer makes sense In browser design leads to a better understanding of what constraints might exist, as well as possible areas to innovate using client side technologies More buy in from the devs to implement as they're part of the process Much easier to design for interaction this way Developer/QA Don't have to interpret steps to reproduce or email/IM a million questions back and forth - it's easier to just show the issue This is perhaps more beneficial on front end work. It just saves time. It encourages a single piece flow to fix QA issues. Show and tell, fix, and a quick check in browsers... suddenly work starts to flow across the Kanban board quicker - as opposed to a pile up at QA and then having to get your head back in there... Can get quick feedback on all browsers, they're checking their machines against integration as soon as we push changes...I don't get pulled off task 3 days later because there's a bug in IE7 Developer/Developer You write better code, period. Just like TDD, It kicks you out of autopilot and forces you to think more about how you are developing because you may have to explain it Unlike code reviews, we can typically make pairing happen. When external pressure comes in, code reviews are the first thing to go as the code is already written. It really helps spread the adoption of internal coding styles, internal frameworks, and allows each of us to jump into any project...
- Fatigue Sometimes our brain says enough...this is ok. It typically means you've absorbed a lot. A lot of times we try to force ourselves to continue out of a feeling of obligation... Focus problems lead to distractions or just wasted resources Interpersonal issues...or becoming "too familiar" Many of us work remotely or are friends and this seems to compound the issue. Know how it bothers you when your significant other constantly shakes their foot on the couch or answers the phone when you're watching game of thrones? That level of annoyance goes double when you're trying to solve a difficult problem Tension It's important to keep external pressures in check... When you have a bad standup or feel under the gun it's easy to leave manners at the door. Disagreements taking too long A lot of the people I work with enjoy arguing...more than actually doing anything. Academic debate can be beneficial, but it's often destructive while pairing if not kept in check. Rabbit Holes or Tangents Similarly, you could be having a disagreement that has very little to do with the problem you are trying to solve.
- Working Agreement If you start to feel your attention waning, stop and take a break. This will hopefully prevent the pairing from devolving into distracting or angering behavior. Fatigue from learning while pairing is legit, there's no shame in having your fill and needing a break - resume when you feel like you can. If you start to feel yourself getting annoyed or angry, stop and take a break. Come back to pairing once you no longer feel this way. As a code driver, pause every once in awhile and check comprehension of the passenger As a code passenger, if you don't understand where the car is going ask them to pull over and explain. Understanding is a key to maintaining focus and limiting distractions, as well as increasing the chances of positive contribution If you are not actively commenting on the code or problem you're pairing on, mute. This will limit distracting sounds from fidgeting, and force people to consciously un-mute to make a statement (hopefully limiting unrelated and distracting comments) Treat all pairing sessions with the same courtesy and respect you would a meeting that the COO was in. Mute for phone calls, excuse yourself from the call, etc. Working remotely or with your friends it ’ s easy to take certain liberties or not show respect.
- Settling disagreements - especially when there are multiple right answers. Identify the problem you are solving. Start with clear goal or stated intent. If an issue comes up and isn't related, note it and table it. The more resources you pull in, the more important this becomes If there is a tool to settle a disagreement - use it In developer pairing, we'll often have disagreements on coding style or micro optimizations which tend to recur and affect consistency in the code base. For Javascript we use things like jsperf.com to run perfomance tests on small blocks of code. For UX, sometimes a coin or thumb vote (with an odd numbered group) combined with a timebox is your best ally. We often spend too much time debating and not enough time testing a hypothesis. If an agreement can not be reached after a predetermined amount of time, arbitrarily pick one and test
- Use the Active Decision Model to record everything How it helped QA/Dev relationships We often have disagreements between QA and Developers about what constitutes fringe case is. Typically dev's think something is fringe and QA doesn't we had no real framework for handling this... it would go back and forth for days with no resolution - and finally drop off. half the time the issue wouldn't be recorded anywhere and members of the QA team started to feel ignored or snubbed People took it personally, it caused bitterness and made it harder to work on the next issue - you could feel the tension building... Simply by agreeing on a process to determine how we decide as a group what is and isn't fringe (or in this case what we would and wouldn't address) bitterness went away (even on the losing side). If we chose to "actively ignore" something as a group rather than passively ignoring it until it went away - there were suddenly no hard feelings. Ignore, Innovate, Best Practice, Dissolve
- We developed some custom frameworks and common code bases at TLC that we wanted to get other teams to start using. We told people about it, did a pretty broad code review where attendance was optional Fast forward half a year... Not only was none of the new framework code being used by other teams, but they had written their own... or had made strides to implement some aspects and did not understand. There was a clear divide between products, we were pairing at times - but mainly within the same product teams This all changed when we started hopping around teams, having floaters that would pair on problems and fill in on multiple teams. For a week or two we had two developers not tasked on any project... By floating we were able to cross-pollinate ideas, improving our framework and receive buy in and understanding for it. This is something we're still working on
- Pairing specialists of different domains is a great way to be able to reduce the overall learning curve with problem solving at the same time help the specialists gain general understanding outside their domain It also reduces the fish out of water feeling and give you confidence to rock out a problem.