3 ms·

That sounds like an interesting exercise. I would like to know about the 'red cell' scenario. Could you give examples of when someone would color a cell red? M

That sounds like an interesting exercise. I would like to know about the 'red cell' scenario. Could you give examples of when someone would color a cell red? My trouble is, a month is a super long time. So long as we are talking features, how messy does something have to be for someone to be unwilling to touch it (after a month)? Could it make sense to simplify this and merge yellow and red together? Or change the definition of yellow to be 4 hours of code grokking (which would mean if I were paged, i could resolve the issue, but it'll take all night rather than knowing exactly where the problem is within 20 minutes)

somethoughts 4y ago
Thanks! Definitely just made all of this spreadsheet up so feel free to modify to suit your team specifics. As the generator of the spreadsheet I may have marked up the spreadsheet for myself as red for stuff I didn't understand but wanted/needed to understand - to reduce team bus factor - in order to show non-technical management what I wanted to spend time on to close the gaps. I also filled out some other team members' column and based on discussions would mark theirs as red. I think the context of a month for yellow was "it would take a month to proactively grok the code (prior to any systems down/bug triage) as a 20% activity on top of other ongoing activities (stand-ups, your existing OKRs, support requests)" - so like 1 day a week dedicated to sitting down to grok Other People's Projects. And now that you mention it - I might have said 2 weeks when I original shared the spreadsheet - so 16 hours to go from yellow->green. Also important is to take snapshots periodically to encourage/reward improvements to making the spreadsheet red -> green. A good work output to demonstrate a red->green transition is 1-2 small feature/bug fixes to a feature and/or a documentation update.
411111111111111 4y ago
Well, i can think of at least one previous situation in which i'd not be confident in changing anything about it even after a month. It happens when you're uncertain if what you're changing is going to break something that doesn't have explicit coverage or is mocked to a degree that the proposed changeset wouldn't cause the tests to fail. I remember a company that had a spelling mistake in a central location of their code. When this spelling mistake was corrected, errors started to pop up days, weeks and months later forcing a revert of this correction several times. So yeah, these things exist

somethoughts 4y ago

Thanks! Definitely just made all of this spreadsheet up so feel free to modify to suit your team specifics. As the generator of the spreadsheet I may have marked up the spreadsheet for myself as red for stuff I didn't understand but wanted/needed to understand - to reduce team bus factor - in order to show non-technical management what I wanted to spend time on to close the gaps. I also filled out some other team members' column and based on discussions would mark theirs as red. I think the context of a month for yellow was "it would take a month to proactively grok the code (prior to any systems down/bug triage) as a 20% activity on top of other ongoing activities (stand-ups, your existing OKRs, support requests)" - so like 1 day a week dedicated to sitting down to grok Other People's Projects. And now that you mention it - I might have said 2 weeks when I original shared the spreadsheet - so 16 hours to go from yellow->green. Also important is to take snapshots periodically to encourage/reward improvements to making the spreadsheet red -> green. A good work output to demonstrate a red->green transition is 1-2 small feature/bug fixes to a feature and/or a documentation update.

411111111111111 4y ago

Well, i can think of at least one previous situation in which i'd not be confident in changing anything about it even after a month. It happens when you're uncertain if what you're changing is going to break something that doesn't have explicit coverage or is mocked to a degree that the proposed changeset wouldn't cause the tests to fail. I remember a company that had a spelling mistake in a central location of their code. When this spelling mistake was corrected, errors started to pop up days, weeks and months later forcing a revert of this correction several times. So yeah, these things exist