<div dir="ltr">Thanks everyone for your experience and suggestions.<div><br></div><div>Something we've implemented this week is having a daily "merge face"</div><div>who takes ownership of getting PRs merged, and code deployed to Production.</div>

<div>(we continuously deploy to QA already)</div><div><div><br class="">Pairing is something we'd like to do, but haven't got it down yet</div><div>(also we have only got 3 devs on the core app, so there'd always be one dev on their own)</div>

</div>
<div><br><div>We've got our retrospective on Friday,</div><div>so we'll see what takeaways we have ongoing from this.</div></div><div><br></div><div>Thanks all.</div><div class="gmail_extra"><br><div class="gmail_quote">


On 21 August 2013 05:46, Mark Burns <span dir="ltr"><<a href="mailto:markthedeveloper@gmail.com" target="_blank">markthedeveloper@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr">It's a bit of an avoid the question type of answer, but we tend to have a rule that pull requests are only<div>for work that hasn't been paired on.</div><div><br></div><div>Pairing mitigates the issues of context switching, blocking, interrupting, etc.</div>




<div>It also improves team-wide communication, understanding of any of these types of process ideas,</div><div>understanding of coding standards or evolving design patterns, sharing nifty command-line tricks or</div><div>




text-editor wizardry, and general camaraderie.</div><div>Design patterns, or even proposed or evolving design patterns are the hardest ideas to communicate</div><div>via either the code itself or comments.... </div></div>

</blockquote></div></div></div>