Today I would like to share a helpful little tip. It will help you avoid problems in the future. But first the backstory.
My team is new to the company. Our average tenure with the company is about six months. And with a new team, it always takes time for the team to bond. And we’re doing great.
Anyway, to establish some norms, we use Working Agreements. Working Agreements can be helpful if done right.
We keep Working Agreements short and sweet. Three to five is plenty. And we review them during Sprint review. We ask questions like “are we living up to them,” and “are they helping.” And we have seen a lot of success from working agreements.
One of our Working Agreements states that we need to peer review pull requests within two days. How awesome is that?
I opened a pull request which took a manual process and automated it to cut toil. Don’t get me started on toil. For now, suffice it to say that toil is terrible and eliminating toil is good.
Unfortunately, the manual task got ahead of the code as the pull request waited for reviews. I had to update the pull request again and again.
That’s usually a preventable problem, but sometimes it’s not. If you can’t prevent it, at least leave yourself a note. When you create a pull request, leave a note at the top of the pull request description. It can be short and sweet. “Don’t deploy until I update foobar.” Or “not safe to merge until we merge that other thing.”
That little trick will allow us to avoid problems. Have you noticed that the best engineers have the best habits? That’ll be a blog post for another day.