search

cloudfour / guides

Conventions, processes and notes about how we do things
24 stars 1 forks source link

Add Rituals Guide #56

Closed spaceninja closed 5 years ago

spaceninja commented 5 years ago

This PR adds a new section for common rituals, and kicks things off with guides for Retrospectives and Postmortems.

spaceninja commented 5 years ago

The Retrospective guide is one I wrote at a previous job. The Postmortems guide I just pulled together and is mostly assembled from the links at the bottom of the doc.

I'm 100% open to feedback, and I'm not suggesting these are ironclad processes we should always follow. More like a helpful jumping-off point if you're on a project where they would be useful.

Paul-Hebert commented 5 years ago

I'm not suggesting these are ironclad processes we should always follow. More like a helpful jumping-off point if you're on a project where they would be useful.

I think it would be good to include something to this effect in the main Rituals README

Paul-Hebert commented 5 years ago

(I approved since I think this is great, but I'm curious what others think)

tylersticka commented 5 years ago

I would hold off merging until @megnotarte reviews. She has her own templates and guidelines for retrospectives and I have no idea how they do or don't gel with what's proposed here.

megnotarte commented 5 years ago

Heya @spaceninja. Thanks for taking the lead on this. I don't think that project processes like project retrospectives should be included here. While our retrospective processes could stand for some additional rigor, I think these should be led by the PM team, and GitHub doesn't seem like the right place for that.

Also, I'm not sure the content applies to our work as broadly as it is stated here. We're not often able to devote an hour every two weeks to a retrospective, for example. Sprint retrospectives do not last that long, and project retrospectives generally happen after a release, or after the end of a project. We're not often afforded the luxury of having a neutral-third party to run any retro, unfortunately. We're just not that big, and our projects don't necessarily require that.

If you'd like to add some documentation around sprint retrospectives here, I think that could be OK. I tend to think of a project retro and a sprint retro as different beasts.

Totally open to chat about this further. As I mentioned above, I do believe we could use additional rigor on this part of our process. Otherwise, perhaps we can just drop the retros part of this for and move forward with the rest? Or tailor to sprint retros specifically.

Love the post-mortem stuff. Historically, I've avoided the use of that term, since it's very negatively charged and people tend to use it in place of a project or sprint retrospective. In this case, it is related to a negative incident, and not just a retrospective, so I'm good with it. I'm curious how much we'll actually use it - we aren't always on the delivery path for client work so the notion of SLA or production type events is not always a thing for us. Good to have, regardless, and I love how quickly you were able to pull it together for last week's not-our-fault issue.

spaceninja commented 5 years ago

@megnotarte that all makes sense, and I think it's totally fair to say what I've outlined here for retros doesn't align with how we do work here. I'll kill the retro doc and leave that up to the PM team to handle.

Does anyone have any other feedback on the postmortem doc? Does it belong here in GitHub or is there a better home for it?