Just read this and wow it really hits a nerve…what do you think? Are they right? Overly optimistic? Or maybe on to something?
I like the approach (it actually spans a much wider construct than just PRs, you could apply it to a whole field of issue resolution etc, but back to topic ). What stands out for me on first pass is this
Not every team member will be present every day. Let’s take a page from distributed systems and require a quorum of team members present when we make code changes. At least 2 developers on a team of 3, at least 3 on a team of 5, etc. That way, whenever it’s time to change that code again, someone present was involved in the most recent change.
Do we actually over time and due to load end up with pair programming or some other micro-team and back into the problem of the more eyes not having the right context? Does the problem actually arise on how we identify all the value we want to put into our products and poor prioritisation?
@rob.vanstone great questions! I’ve seen so many orgs like the general idea of pair programming but never really do it. I had some connections at Home Depot when they started to go all in with XP in one of their areas and heard it was amazing how much code quality improved as well as throughput when the implemented pair programming. I think it’s something teams should try for a few sprints and just experiment with…and then consider doing some mob programming as well. It’s interesting to me how much gets done in a hackathon. Usually in those conditions a few patterns emerge…teams know exactly what the vision is (often they come up with it) and everyone jumps in to help, often unintentionally pairing throughout the exercise. They emerge with demo-able functionality that they are engaged with and almost 100% of the time management is pleasantly surprised with the creative deliverables. I think we could take a page from that book and try to create those conditions more regularly…at minimum sharing a broad vision, giving teams the space to be creative in organizing as they’d like and solving for that vision.